Re: [lwip-users] Ethernet driver for OS

[Jeff Barber]

On Mon, Aug 30, 2010 at 3:52 PM, Timmy Brolin <address@hidden> wrote:
> I am wondering if anyone could give me a pointer or two on the most
> appropriate way to implement a Ethernet driver.

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


> For Rx, I guess it could be possible to do all Rx processing in the ISR,
> but it is quite a lot of processing for an ISR. And I am not too happy
> about putting pbuf_alloc() (for filling the Rx ring) and pbuf_free()
> (for dumping damaged frames) calls in an ISR. What if the pbuf pool is
> locked when the ISR runs?

I think if you go this route, the process of locking the pbuf pool
would also need to disable interrupts; then you won't have this
problem.  However...

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

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.

Jeff