> > 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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
