Re: [lwip-users] Ethernet driver for OS

[Jeff Barber]

On Thu, Sep 2, 2010 at 2:43 PM, Timmy Brolin <address@hidden> wrote:
> Jeff Barber wrote:
>>> For Tx it is pretty straightforward, I'll just write a
>>> low_level_output() function which will be called from the lwip thread.
>>> But how do I clean up the buffer descriptors when the transmission is
>>> complete? Am I really supposed to create a new thread just to clean up
>>> the Tx buffer descriptors, or is there a better way?
>>>
>>
>> The way to do this is to increment the reference count of each buffer
>> handed to your driver (with pbuf_ref()).  This way the buffer will not
>> be deallocated when your caller frees it (non-zero ref count).  When
>> the transmission is complete later, you call pbuf_free() yourself --
>> the ref count goes to 0 and pbuf_free actually releases the buffer.
>>
> Yes, but how am I supposed to call pbuf_free() "myself"?
> Somehow I need to wake up the lwip task to do this cleanup, right? I
> have not yet found how to do this in a "standard" way.

When your driver's "low_level_output" function is called to initiate
the send, you call pbuf_ref so the buffer won't go away.  Next you put
the frame data address into the transmit descriptor and queue it to
the MAC.  You then have to store the pbuf pointer somewhere while the
frame is in the MAC being transmitted.  When the MAC indicates it's
finished sending (which you probably recognize in a subsequent call to
your driver's poll function), then you call pbuf_free to release the
buffer space.


>>> Is there a better way? Is it possible to have the Rx ISR signal the lwip
>>> thread, and have the lwip thread process the Rx descriptors?
>>> I would prefer not having to create a Rx thread just for processing the
>>> Rx descriptors, since that would cause an extra task reschedule at the
>>> reception of every frame.
>>>
>>
>> Yes; this is what I would do (and essentially the same thing I do now
>> -- albeit in a single-threaded environment): have the ISR merely
>> wake-up/schedule the lwip thread.  The lwip thread then polls the
>> driver, which processes incoming descriptors and passes the frames up
>> the stack.  The driver poll function can also do other things needed:
>> restock rx descriptors to replace the buffers used by processed frames
>> as well as push descriptors for any frames to be transmitted onto the
>> tx queue.
>>
> We are obviously thinking the same way... But is there a standard
> interface in LwIP for doing this, or do I have to modify the LwIP source
> to add this ability?

Hmm... looks like I may have misled you on this.  Poking around a bit,
it appears that with NO_SYS=0, it is typical to have a main thread (rx
thread) that polls the driver separate from the tcpip_thread(). It
appears that the main thread enqueues packets to the tcpip_thread for
processing.  More specifically, it passes tcpip_input as the input
function to the netif rather than passing it the ethernet_input. So
that when the main thread receives packets, it calls tcpip_input to
pass them to tcpip_thread via the mailbox/mbox abstraction.

So while it does seem feasible to me (unifying the main/rx thread and
the tcpip_thread), you would definitely have to modify or at least
copy the source since tcpip_thread is a static function.

I've never used lwip with an operating system and had made incorrect
assumptions about it.  Sorry for the confusion.

>
> I prefer to keep as many of the LwIP source files as possible unmodified
> to make updates to future LwIP versions easier.

>> The core of lwip cannot run in multiple threads concurrently so it's
>> not clear to me that you really have much choice here anyway.

This was also misleading as noted above.

>>
> I see that there is a task registered on svannah related to this, where
> it has been suggested that it would be better if LwIP had a "big stack
> lock" semaphore instead of the current mailbox system.
> I think such a change would make a lot of sense, since it would increase
> performance by reducing the number of task reschedules. It may even
> reduce the RAM and ROM footprint of LwIP somewhat.

Jeff