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
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users