[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] Comments about "low_level_output"
From: |
Jonathan Larmour |
Subject: |
Re: [lwip-devel] Comments about "low_level_output" |
Date: |
Thu, 24 May 2007 17:24:37 +0100 |
User-agent: |
Thunderbird 1.5.0.10 (X11/20070301) |
Frédéric BERNON wrote:
Before one of last commits (for bug #3168), "sendto" on udp or raw
didn't return any error if the netif's low_level_output return something
different than ERR_OK. It wasn't so good, but now, it's fixed. But
during one of my unit tests to measure performance (a "hot" subject), I
have note that the test failed (and of course, always succes before): in
fact, because I had fill all my device MAC "descriptors", my
low_level_output return a ERR_IF error (/* Low-level netif error */).
And because this error is now return until conn->err, API stop to send,
and even application got the error. All these errors checkings are good,
but functionally, it's not correct. So, my questions:
1/ What do you think that a "low_level_output" function should return
when all "buffers" are full?
If returning an error, ERR_MEM seems most appropriate - you have run out of
buffer memory.
2/ Is it something you do in your ports to "block" inside
low_level_output to wait some space to send? (I don't think, but...)
I give my own users a configuration choice - wait for a few milliseconds
(and drop if times out), or just drop the packet right away. But I haven't
integrated Simon's patch for bug #3168 so I hadn't been thinking about
returning an error. Waiting is not ideal as the whole stack blocks.
3/ Isn't it something to document anywhere? I think, but where? I
thought to rawpi.txt...
Maybe. Although since transmission (and Ethernet generally) isn't always
reliable anyway, you can never guarantee that something you think was sent
was really received. Error means really an error, but OK doesn't mean no
error. Still, it's probably good to pass the error I think.
4/ Should we have to "filter" such "temporary errors" inside do_xxx
functions? (It will add some code, and increase footprint, so, I don't
like that)
I don't think so. Particularly for something like UDP you may not care that
it gets lost. If you want something reliable, you don't use UDP! (Or if you
do, not by itself).
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------ Opinions==mine