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

[address@hidden]

Siva Velusamy schrieb:
> 1. It is actually ok for the adapter to queue packets if they cannot
> be sent right away. I do not feel comfortable creating one more queue
> at the MAC adapter level, but it seems unavoidable since the MAC has a
> TX FIFO of just 2k and could easily be overrun by just a single UDP
> send of a packet > 2k in size.
>   
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).

You'r right that returning an error (packet could not be sent) when the 
MAC is full will
lead to too many packets lost for UDP and many retransmissions with TCP.
> 2. The best way to structure this queuing code would be to follow
> something similar to what etharp.c does to queue multiple fragments.
> i.e., just alloc a new pbuf, and copy over the contents of this chain
> into the new pbuf.
>   
Be aware that this code is rather slow since it uses the processor to 
copy the packet. While this is OK
for etharp (doesn't happen that often if you configure the ARP table 
size to your needs), this might
greatly reduce performance when done for every packet sent.

lwIP actually has an open issue there with DMA enabled MACs which is 
quite similar to your porblem:
DMA enabled MACs _always_ queue pbufs they want to send (queueing the 
payload pointers, not the
pbuf structs) which might result in sending wrong data if the payload 
gets modified later (since the
netif->output function returns before the packet is actually sent). This 
is not yet solved, I think.

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


Simon