[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Low-level interface error handling - request/suggestion
From: |
Simon Goldschmidt |
Subject: |
Re: [lwip-users] Low-level interface error handling - request/suggestion |
Date: |
Fri, 29 Jul 2016 12:32:09 +0200 |
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