RE: [lwip-devel] Comments about "low_level_output"

[Pettinato, Jim]

As a raw interface user, I was surprised to see the stack didn't handle an 
error situation in low_level_output. Luckily I'm using TCP based apps almost 
exclusively so I can let the protocol handle retries, and hence just drop the 
outgoing packet. It would be nice to handle this in the core somehow if 
possible from my perspective.

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of Jonathan Larmour
Sent: Thursday, May 24, 2007 12:25 PM
To: lwip-devel
Subject: Re: [lwip-devel] Comments about "low_level_output"


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


_______________________________________________
lwip-devel mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-devel