I've ran into this problem on my products as well, but the situation is a little different. We use LwIP on top of a WiFi subsystem and it's easy to fill up the driver's transmit queue when the device (operating as a station) moves out of range of the AP.
We've handled it in two manners, both have pros/cons: 1) Block the calling thread until space opens up in the driver's transmit queue. This became problematic because the sending thread was blocked for a long time in the out of range case. We've mainly seen this with UDP sockets because there is no socket buffering and each UDP sendto() calls right into the driver. I believe it can happen with TCP too because LwIP does tcp_write() and then tcp_output() (which would block in this scenario). 2) Drop the packet when the transmit queue is full. We've been using this behavior when the long blocking is unacceptable. Cons here are mainly for UDP where the packet is dropped (TCP will at least retransmit). This isn't too much of a concern for us because in the out of range case, you get a lot of dropped data anyways. I think the ideal system for non-blocking sockets is to propagate the out of resource message. For TCP, that means leave the packet in the send buffer (if send buffer is full, packet is rejected and return EWOULDBLOCK). For UDP, reject the send since there is no buffering and return EWOULDBLOCK. This lets the application know it can't send right now and gives the application the option to stop generating data until the socket is marked as writable again. Blocking sockets is much simpler as we just remained blocked until the driver lets us transmit :) The TCP pathway is probably closer to supporting this now as we do have some handling for out of memory errors. The UDP pathway would need work and to leverage a callback as described by Simon in order to mark the socket as writable again (once callback is triggered) Joel On Aug 29, 2016, at 02:01 PM, "[email protected]" <[email protected]> wrote: 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 [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
