Re: [lwip-users] Ethernet driver for OS

[Timmy Brolin]

Jeff Barber wrote:
>> First of all, the MAC we are going to use it pretty standard. It uses
>> DMA transfers and linked buffer descriptors just like most other modern
>> MACs. I will implement a zero-copy driver for both Rx and Tx.
>>
>> 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.

>> 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?

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.
>   
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.

Regards,
Timmy Brolin