[syslinux] [PATCH][GIT-PULL] lwIP undiif: Fixes for VMware platforms and general fixes

[Gene Cumm]

On Fri, Oct 21, 2011 at 06:15, Eric W. Biederman <ebiederm at xmission.com> wrote:
> Gene Cumm <gene.cumm at gmail.com> writes:
>
>> On Thu, Oct 20, 2011 at 21:11, Eric W. Biederman <ebiederm at xmission.com> wrote:
>
>>> tcpip_input always calls ethernet_input if you are an ethernet device.
>>> So the only practical difference is bounding through an extra thread.
>>>
>>> Maybe there is a good reason for bouncing through an extra thread.
>>> I seem to have vague memories about it just being plain less efficient
>>> and killing through put.
>>
>> A wider window helps to a point.
>>
>>> I did not use tcpip_input deliberately.  At the very least because it
>>> was an apparent unnecessary complication.
>>>
>>> I guess I would tend to focus on why are we not ready to receive
>>> a packet?   That sounds like a more straight forward bug to fix than
>>> weird crazy timing issues.
>>
>> tcp_output() eventually leads to undiif_output() but before returning
>> all the way, the packet is receieved on undiif_input().  If we attempt
>> at this instant, there is no open socket.  If we attempt once
>> tcp_output() finishes, the PCB is finalized and the socket is valid.
>> I have some lengthy debug output of failures and successes if you'd
>> like (including extra statements I put in and have prepped in a branch
>> purely for debugging that I can publish if you wish to see it)
>
> I think looking at the traces would be useful.  There is something else
> interesting in all of this.  To run the interrupt handler we already
> have to switch threads.  I think that is what ultimately led me to
> thinking calling tcpip_input was just plain silly.
>
> I forget the task switching model but perhaps it would be worth
> playing with a voluntary preemption point.  Or maybe what we need
> instead fewer threads.
>
> Doh! What tcpip_input gets us is that we run everything single threaded.
> Let me just say that lwip has the most convoluted idea of a bit network
> stack lock that I have ever seen.  Posting messages in a multi threaded
> context so a single thread can do all of the work.
>
> So I guess at that level using tcpip_input makes a lot of sense. Less
> multitasking so there are fewer surprises.
>
>>> To make things particularly clean and beautiful the arp layer needs to
>>> be abstracted away from ethernet.  But that hasn't happened yet.
>>
>> This has me leaning towards not setting that flag so that lwIP doesn't
>> think it can do ARP itself.
>
> I don't follow.  We always need to do ARP.  The UNDI layer doesn't know
> how.  So lwip in some form will always need to do arp.
> question is do we generate the link layer header ourselves.

By this I mean that it would be up to the UNDI and undiif to address
ARP as the UNDI might not be Ethernet in the first place.  This would
accelerate the logic path decisions but won't change the need to let
the sender finish up the packet before the receiver can demux
properly.

> After having realized that the point of the tcpip_thread is to
> single thread the tcpip stack.  I have cooked up the following
> untested patch.  But I think it solves our issues cleanly.
>
> Does that patch fix your issues?
>
> Eric

Aside from the lack of core/lwip/src/include/netif/undiarp.h and a
minor patch issue in the tail (spacing), it can apply.  This does
appear to function.  So tcpip_thread() only uses undi_input() on
non-Ethernet  but I also don't see NETIF_FLAG_UNDIARP being set on
flags (I'd presume to be implemented in the future).

-- 
-Gene