Re: [lwip-users] Low-level interface error handling - request/suggestion

[Simon Goldschmidt]

Mike Fleetwood wrote:
> I am using ST's ethernetif.c driver for STM23F427, which occasionally
> returns ERR_USE. The reason this return code is used, rather than any
> other is explained by ST in the function header:

So STM decided to return "Address in use" (ERR_USE) when they cannot enqueue a 
tx packet
in the DMA ring. That's a bogus error code for this error condition. This might 
be a valid
approach as ERR_MEM indeed has some other side effects (e.g. the http server 
retries
writing less bytes, etc).

However, ERR_USE is clearly the wrong error here, since it does not point to 
the error
source at all.
ERR_IF might have been better, but this is marked as fatal in the lwIP version 
they ship,
so this is not an option as well.
ERR_BUF might have been better, but in the end there is not a real difference 
to using ERR_USE,
as the stack does not check error return values other than ERR_MEM and 
ERR_IS_FATAL().

> So, my request is: is it possible for future versions of LWIP detect
> this return from the low level driver and either impliment some recovery
> (presumably short wait, then re-try would allow the DMA buffer to
> clear),

I could imagine that for TCP (some kind of trigger callback that results in 
calling tcp_output()
on all pcbs), but there's no way to do that for UDP (we do not have cached 
pbufs to retry).

Instead, the netif driver might want to keep a list of pbufs to transmit and 
queue them in
a software queue if the (hardware-) DMA queue is not big enough.

> or, at least report the error in a meaningful way to the higher
> layers?

That's easy: make the netif driver implementation return a meaningful error.
ERR_IF would be correct, but that doesn't work until fatal error handling has 
been fixed.
ERR_BUF would be OK for now, I guess.

> Currently, this error would appear to be fatal.

No, it's not (unless you use a pre 1.4.0 version of lwIP).
It should continue working once there's room in the DMA ring again. That makes 
me think there's
some kind of race condition in the driver.

> As to why it should happen in the first place - that is another problem!

That, too, makes me think of a bug in the driver, given the timings you 
discribed in your last mail.


Simon