summaryrefslogtreecommitdiff
path: root/net/atm/resources.h
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw2@infradead.org>2012-11-25 12:06:52 +0000
committerDavid S. Miller <davem@davemloft.net>2012-11-26 17:13:56 -0500
commitae088d663beebb3cad0e7abaac67ee61a7c578d5 (patch)
tree5b46bae47a0cd42a04541b32b6da41f84345f6c6 /net/atm/resources.h
parentb3422a314c27d2189c05b69cc1654b71315d3d21 (diff)
atm: br2684: Fix excessive queue bloat
There's really no excuse for an additional wmem_default of buffering between the netdev queue and the ATM device. Two packets (one in-flight, and one ready to send) ought to be fine. It's not as if it should take long to get another from the netdev queue when we need it. If necessary we can make the queue space configurable later, but I don't think it's likely to be necessary. cf. commit 9d02daf754238adac48fa075ee79e7edd3d79ed3 (pppoatm: Fix excessive queue bloat) which did something very similar for PPPoATM. Note that there is a tremendously unlikely race condition which may result in qspace temporarily going negative. If a CPU running the br2684_pop() function goes off into the weeds for a long period of time after incrementing qspace to 1, but before calling netdev_wake_queue()... and another CPU ends up calling br2684_start_xmit() and *stopping* the queue again before the first CPU comes back, the netdev queue could end up being woken when qspace has already reached zero. An alternative approach to coping with this race would be to check in br2684_start_xmit() for qspace==0 and return NETDEV_TX_BUSY, but just using '> 0' and '< 1' for comparison instead of '== 0' and '!= 0' is simpler. It just warranted a mention of *why* we do it that way... Move the call to atmvcc->send() to happen *after* the accounting and potentially stopping the netdev queue, in br2684_xmit_vcc(). This matters if the ->send() call suffers an immediate failure, because it'll call br2684_pop() with the offending skb before returning. We want that to happen *after* we've done the initial accounting for the packet in question. Also make it return an appropriate success/failure indication while we're at it. Tested by running 'ping -l 1000 bottomless.aaisp.net.uk' from within my network, with only a single PPPoE-over-BR2684 link running. And after setting txqueuelen on the nas0 interface to something low (5, in fact). Before the patch, we'd see about 15 packets being queued and a resulting latency of ~56ms being reached. After the patch, we see only about 8, which is fairly much what we expect. And a max latency of ~36ms. On this OpenWRT box, wmem_default is 163840. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/atm/resources.h')
0 files changed, 0 insertions, 0 deletions