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

[Siva Velusamy]

>
> You can also just wait for the MAC being free again. This might sound
> ineffective, but
> creating a second pbuf via memcpy might be as ineffective (depends on
> your system).

makes sense, and should be easy enough to benchmark. Thanks for the suggestion.

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

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.

Another thing that would be good to know is what paths actually change
the headers after netif->output returns after just enqueing the data.
If this is only in a few places, then it might be easier to change
those places rather than the adapter.

Thanks!
Siva