Comments about "low_level_output"

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Comments about "low_level_output"

Frédéric BERNON
Message
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?
 
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...)
 
3/ Isn't it something to document anywhere? I think, but where? I thought to rawpi.txt...
 
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)
 
My current workaround is to return ERR_OK in the place of ERR_IF in this case (it's just affect my port, and, after all, a packet could always be lost in the network...)
 
Thank you for your comments...
 
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]r
Web Site : http://www.hymatom.fr
====================================
P Avant d'imprimer, penser à l'environnement
 
 

_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments about "low_level_output"

Jonathan Larmour
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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: Comments about "low_level_output"

JamminJimP

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: lwip-devel-bounces+jim.pettinato=[hidden email] [mailto:lwip-devel-bounces+jim.pettinato=[hidden email]] 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
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-devel


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: Comments about "low_level_output"

Kieran Mansley
On Thu, 2007-05-24 at 13:18 -0400, Pettinato, Jim wrote:
> 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.

For TCP we should be able to notice this error and leave it on the sent
queue.  This would be much better than dropping and retransmitting as
that really hurts performance, but perhaps that performance hit is
actually a good thing as you should then give the device that has run
out of memory time to catch up.

Kieran



_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE: Comments about "low_level_output"

Goldschmidt Simon
In reply to this post by Frédéric BERNON

>  1/ What do you think that a "low_level_output" function should return
when all "buffers" are full?
 
ERR_MEM seems good to me.
 
> 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...)
 
No.
 
> 3/ Isn't it something to document anywhere? I think, but where? I
thought to rawpi.txt...
 
Yes!
 
> 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 think the real question is "why don't we allow a send if the previous
send went wrong?"

That seemed strange to me when I first looked over the code. More, if I
call netconn_addr() after a send that went wrong, I can always send
again! I think instead of filtering out ERR_MEM, we should somehow
rework the whole conn->err related code.

 
> My current workaround is to return ERR_OK in the place of ERR_IF in
this case (it's just affect my port, and, after all, a packet could
always be lost in the network...)
 
That works,  of course, but it's really a workaraound, not a solution.


Simon


_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel
Reply | Threaded
Open this post in threaded view
|

RE : Comments about "low_level_output"

Frédéric BERNON
In reply to this post by Frédéric BERNON
>That seemed strange to me when I first looked over the code. More, if I call netconn_addr() after a send that went wrong, I can always send again! I think instead of filtering out ERR_MEM, we should somehow rework the whole conn->err related code.

Yes, agree with you. But first strange thing it there is a change in netconn_addr (like in netconn_peer). I think the initial use of conn->err was to return fatal errors, to avoid some deadlocking case, like in netconn_recv (if you got an error, but didn't check conn->err, you could redo an netconn_recv, which wait forever because no other msg would be post by err_tcp)...

Other thing about error code, see https://savannah.nongnu.org/patch/?5960...
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-devel-bounces+frederic.bernon=[hidden email] [mailto:lwip-devel-bounces+frederic.bernon=[hidden email]] De la part de Goldschmidt Simon
Envoyé : mercredi 30 mai 2007 09:27
À : lwip-devel
Objet : RE: [lwip-devel] Comments about "low_level_output"



>  1/ What do you think that a "low_level_output" function should return
when all "buffers" are full?
 
ERR_MEM seems good to me.
 
> 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...)
 
No.
 
> 3/ Isn't it something to document anywhere? I think, but where? I
thought to rawpi.txt...
 
Yes!
 
> 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 think the real question is "why don't we allow a send if the previous send went wrong?"

That seemed strange to me when I first looked over the code. More, if I call netconn_addr() after a send that went wrong, I can always send again! I think instead of filtering out ERR_MEM, we should somehow rework the whole conn->err related code.

 
> My current workaround is to return ERR_OK in the place of ERR_IF in
this case (it's just affect my port, and, after all, a packet could always be lost in the network...)
 
That works,  of course, but it's really a workaraound, not a solution.


Simon


_______________________________________________
lwip-devel mailing list
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-devel

_______________________________________________
lwip-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-devel

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment