firewire: net: throttle TX queue before running out of tlabels
commitb2268830f5cf29d94b3e4a2af0b795a8f28776fe
authorStefan Richter <stefanr@s5r6.in-berlin.de>
Sun, 14 Nov 2010 13:35:40 +0000 (14 14:35 +0100)
committerStefan Richter <stefanr@s5r6.in-berlin.de>
Tue, 16 Nov 2010 23:08:49 +0000 (17 00:08 +0100)
treea52483756446f1e09dcd80b5243d899612cf5caa
parent48553011cea504796e513350740781ac6745f556
firewire: net: throttle TX queue before running out of tlabels

This prevents firewire-net from submitting write requests in fast
succession until failure due to all 64 transaction labels were used up
for unfinished split transactions.  The netif_stop/wake_queue API is
used for this purpose.

Without this stop/wake mechanism, datagrams were simply lost whenever
the tlabel pool was exhausted.  Plus, tlabel exhaustion by firewire-net
also prevented other unrelated outbound transactions to be initiated.

The chosen queue depth was checked by me to hit the maximum possible
throughput with an OS X peer whose receive DMA is good enough to never
reject requests due to busy inbound request FIFO.  Current Linux peers
show a mixed picture of -5%...+15% change in bandwidth; their current
bottleneck are RCODE_BUSY situations (fewer or more, depending on TX
queue depth) due to too small AR buffer in firewire-ohci.

Maxim Levitsky tested this change with similar watermarks with a Linux
peer and some pending firewire-ohci improvements that address the
RCODE_BUSY problem and confirmed that these TX queue limits are good.

Note:  This removes some netif_wake_queue from reception code paths.
They were apparently copy&paste artefacts from a nonsensical
netif_wake_queue use in the older eth1394 driver.  This belongs only
into the transmit path.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
drivers/firewire/net.c