|
From: | Joel Cunningham |
Subject: | Re: [lwip-users] ethernet driver overloaded? |
Date: | Mon, 29 Aug 2016 20:39:17 +0000 (GMT) |
Hi,
originally, this hasn't been covered by lwIP: the systems were so slow that you basically
never got into that mode (the assumption was that the network hardaware is faster in
transmitting than the CPU is in sending more packets).
Of course, this doesn't hold any more, so today it's assumed that a driver that doesn't
send a frame blocking (easy to implement but bad performance)
a) enqueues a packet into hardware buffers for sending or
b) enqueues the pbuf to transmit on a software list of pbufs that is sent later if
enough harder buffers are free
If it returns "out of memory", TCP will stop sending until for some time, so that's not
a good idea. If it just stops sending, the result is mostly the same. So indeed, a new
return code for "hw full, try again on callback" plus an additional callback might be
best. It is *not* required to achieve good performance, though. It could improve
overall memory usage however.
Simon
Am 29.08.2016 um 12:40 schrieb Alexander Schulz:hi,
in a current project I am trying to send out a relatively large consecutive data stream
using tcp/ip.
I can see that data is handed over to the ethernet driver via the registered function
at “linkoutput”.
what I am missing is the evaluation of a return value indicating that the underlying ethernet
driver is still busy sending. I see that “linkoutput”’s retval goes up to “tcp_output_segment()”
but here, the retval of “ip_output()” is just discarded.
how is the overload at the ethernet driver prevented?
maybe relying on tcp’s recover mechanism could cover this up but I’d like to prefer
avoiding stream errors right in the first place.
maybe I just overlook something…
b.-regards.
Renesas Electronics Europe GmbH,Geschaeftsfuehrer/President : Michael Hannawald, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany,Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
_______________________________________________ lwip-users mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/lwip-users_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
[Prev in Thread] | Current Thread | [Next in Thread] |