[rt2x00-users] reduced transfer speed

[Balint Viragh]

Hi,

I have noticed during transfer-speed measurements, that the  
compat-wireless-2011-04-25 is slower than compat-wireless-2011-02-14.

I have USB WiFi dongles with RT3070 and RT3370 chipsets.
uname -a:
Linux (none) 2.6.35.10 #2 Thu Apr 28 16:28:52 CEST 2011 armvejl GNU/Linux

I used iperf in simple TCP speed test mode,
the results:
2011-02-14: 7.18 ... 6.95 Mbps
2011-04-25: 1.3 ... 3.72 Mbps but it varies, sometimes I measured only 
100-200 Kbps.

I found these results quite interesting, so I started to find the commit 
that cause this performance issue:
I think that this performance issue exists since the following commit:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=10e11568ca8b8a15f7478f6a4ceebabcbdba1018
"rt2x00: Make rt2x00_queue_entry_for_each more flexible"

I applied this and the previous three patches to 
compat-wireless-2011-04-14 to test this issue.

The compat-wireless-2011-04-14 works fine, and there are 3 other commits 
between the compat-wireless-2011-04-14 release and this commit:
 [1] "rt2x00: Split rt2x00dev->flags"
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=7dab73b37f5e8885cb73efd25e73861f9b4f0246
 [2] "rt2x00: Fix stuck queue in tx failure case"
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=62fe778412b36791b7897cfa139342906fbbf07b
 [3] "rt2x00: Enable WLAN LED on Ralink SoC (rt305x) devices"
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=44704e5d7d56625ff93d5a119ca846ae4de9061c

I guess that the new functionality of rt2x00_queue_entry_for_each causes 
the problem:
If the callback function returns true, then the further entries in the 
queue are not processed,
The following functions can return true and stop the queue processing:
 - rt2x00usb_kick_tx_entry
 - rt2x00usb_kick_rx_entry
 - rt2x00usb_flush_entry.
I checked that if these functions never return true, then the 
performance issue disappears.

This workaround also works fine in compat-wireless-2011-04-25:
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c    2011-04-25 
21:03:06.000000000 +0200
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c    2011-05-04 
13:37:38.000000000 +0200
@@ -295,7 +295,7 @@
 
     if (!test_and_clear_bit(ENTRY_DATA_PENDING, &entry->flags) ||
         test_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags))
-        return true;
+        return false;
 
     /*
      * USB devices cannot blindly pass the skb->len as the
@@ -389,7 +389,7 @@
 
     if (test_and_set_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags) ||
         test_bit(ENTRY_DATA_STATUS_PENDING, &entry->flags))
-        return true;
+        return false;
 
     rt2x00lib_dmastart(entry);
 
@@ -444,7 +444,7 @@
     struct queue_entry_priv_usb_bcn *bcn_priv = entry->priv_data;
 
     if (!test_bit(ENTRY_OWNER_DEVICE_DATA, &entry->flags))
-        return true;
+        return false;
 
     usb_kill_urb(entry_priv->urb);
 
---

I am guessing, maybe the conditions in these functions should be fixed.

This can also have influence on the other issue I reported last week, 
about the communication stop in AP mode:
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2011-April/003728.html.
I have tested many times the compat-wirless-2011-04-25 with this 
workaround, and the communication never stops like it does without the 
workaround.

Please check this queue handling issue.
Thank you,

Balint Viragh