lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] question about structuring an lwIP emac adapter


From: address@hidden
Subject: Re: [lwip-users] question about structuring an lwIP emac adapter
Date: Sun, 20 Jan 2008 18:48:01 +0100
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)

Siva Velusamy wrote:

Your problem (although you don't seem to have a DMA MAC but a FIFO) is
quite similar (having a queue).
If you want to queue, you must create a copy of the pbuf, that's right.
But your application might be faster if
you just wait for the last packet being sent instead of copying twice
(duplicating the pbuf and copying it
to the MAC).

gulp! I wrote a dma adapter too which does what you describe. I guess
I never saw issues because this is a race condition between how fast
the DMA transfer happens vs when lwIP modifies the payload.

This seems like an important problem to solve - performing an extra
copy in the DMA adapter would obviously lead to lesser performance.
Could you point me to the bugcase for this issue so I can look at the
suggested workarounds?
bug #21049 and task #6735. The reason it's not included in 1.3.0 is that we kind of couldn't get a fast agreement on how to proceed (since this effectively prevents UDP no-copy sends)...
I'm guessing that one approach could be to make a copy of just the
headers (all the way upto the TCP data), since lwIP is only going to
modify the headers and not the data itself. This would require some
knowledge of protocols in the adapter, but we can probably make the
frequent case TCP transfers reasonably fast by just copying the
headers.
For TCP I think you wouldn't have to copy anything: TCP segments are (to my knowledge) not changed after being sent, they are simply resent as is. Plus TCP retransmit queues make sure the pbufs are allocated long enough to be transmitted: they have to be ACKed before being freed, after all.

This bug _will_ get attention, but we need to get a consensus about this before changing it.

Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]