[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Tx queue filling up

From: address@hidden
Subject: Re: [lwip-users] Tx queue filling up
Date: Thu, 22 Oct 2009 17:29:45 +0200
User-agent: Thunderbird (Macintosh/20090812)

Jeff Barber wrote:
Now 256 happens to correlate to the size of the Tx and Rx ring buffers
in my driver so that was the obvious place to look.  I notice that
sometimes my driver's linkoutput function is being called when its Tx
queue is full.  I'm thinking that's the proximate cause of the
problem.  However, shouldn't the TCP_SND_QUEUELEN (32) and TCP_SND_BUF
(8 * MSS) values be a limit to the maximum number of "outstanding"
pbufs?  I did turn on TCP_QLEN_DEBUG and according to that info, I
never get a queue len > 8.  So why do I end up with so many packets
"in flight"?
That's a good question. The queue len doesn't grow because SND_BUF limits it (assuming you transmitted 8 full mss-sized segments).

When your driver runs out of buffers, did you check these are only packets from one tcp connection? Maybe there are other packets transmitted by your board?
And if I'm misunderstanding, what is the intended feedback mechanism
from the driver?  tcp_output always seems to ignore the return value
of ip_output.  Hence, if I understand it correctly, that means an
attempt to send while the Tx queue is full is treated exactly the same
as if the packet was dropped on the wire: i.e. it will rely on the
retransmission process to recover.
Unfortunately, this really is the case currently. A solution for this isto just delay the lwip sending task until there's room in your MAC's Tx queue. Unfortunately, this also suppresses processing Rx packets while waiting, but at least other tasks can run. The problem is at one point you *have* to slow down the CPU if it tries to send faster than the wire supports. Any input on how this can best be solved in the lwIP code is of course welcome!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]