Re: [lwip-users] Returning ERR_MEM from low_level_output()?

[address@hidden]

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