|
From: | address@hidden |
Subject: | Re: [lwip-users] Returning ERR_MEM from low_level_output()? |
Date: | Thu, 17 Apr 2008 19:54:24 +0200 |
User-agent: | Thunderbird 2.0.0.12 (Macintosh/20080213) |
Ceresoli Luca wrote:
netif->linkoutput is called e.g. from udp_output (which calls ip_output_*, which calls netif->output/etharp_output which calls netif->linkoutput)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.
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).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?
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.And what would be the negative effect of returning ERR_MEM and dropping the packet?
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
[Prev in Thread] | Current Thread | [Next in Thread] |