Ceresoli Luca wrote:
Hi,
from the ethernetif.c skeleton file, the comment to low_level_output():
* @note Returning ERR_MEM here if a DMA queue of your MAC is full can lead to
* strange results. You might consider waiting for space in the DMA queue
* to become availale since the stack doesn't retry to send a packet
* dropped because of memory failure (except for the TCP timers).
I didn't understand the effects of returning ERR_MEM. Trying to backtrack through
the functions that call netif->linkoutput(), I got lost in the graph.
netif->linkoutput is called e.g. from udp_output (which calls
ip_output_*, which calls netif->output/etharp_output which calls
netif->linkoutput)
What would be the correct thing to return when there is no buffering space
available in the driver and it is not possible (or not convenient) to wait?
It doesn't say you may not return an error, but if you really don't
send, you _have to_ return ERR_MEM: (since tcp netconns detect that and
try again).
And what would be the negative effect of returning ERR_MEM and dropping the
packet?
When using sockets, the error is handed on to the user (that has
improved in 1.3.0: in previous versions, you couldn't use the socket
afterwards...). The problem that the citet text wants to describe is
this: suppose you have a very fast processor (i.e. the processor would
like to enqueue packets much faster than they can be sent on the wire)
and ETH MAC with a DMA queue. In this case, when sending UDP data, the
DMA queue will be full very fast, and you will drop many packets unless
at some point you wait until there is room in the DMA queue again.
On the other hand (as I wrote above), the netconn layer should handle
this problem for TCP netconns, so this will only affect UDP packets...
Simon
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
