Send users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Re: [PATCH] rt2800usb: Let rt2x00usb handle USB padding
(Helmut Schaa)
2. Re: [PATCH] rt2x00usb: Zero USB padding before sending URB
(Helmut Schaa)
3. Re: [PATCH] rt2800usb: Let rt2x00usb handle USB padding
(Jakub Kici?ski)
4. rt2880 AP performance (Daniel Golle)
5. Re: [PATCH] rt2800usb: Let rt2x00usb handle USB padding
(Stanislaw Gruszka)
6. Re: [PATCH] rt2x00usb: Zero USB padding before sending URB
(Stanislaw Gruszka)
7. Re: Poor performance and lockup with rt2800usb and Asus
USB-N13 adapter (Stanislaw Gruszka)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Dec 2011 09:44:39 +0100
From: Helmut Schaa <[email protected]>
To: Jakub Kici?ski <[email protected]>
Cc: [email protected]
Subject: Re: [rt2x00-users] [PATCH] rt2800usb: Let rt2x00usb handle
USB padding
Message-ID:
<CAGXE3d-zEKXSqxHqa5cMnNoaj-pa0AS=ynwz+sr05hc79ka...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
2011/12/21 Jakub Kici?ski <[email protected]>:
> Older USB drivers does not append end padding to skb but instead report
> it in size of data to be transmitted to HW. rt2800usb should follow that
> behaviour. Custom write_tx_data callback which was adding pad to skb
> is not be needed any more.
>
> Thanks to this patch frames handed back from rt2800usb to mac80211 will
> no longer contain end padding.
>
>
> Signed-off-by: Jakub Kicinski <[email protected]>
> ---
> ?drivers/net/wireless/rt2x00/rt2800usb.c | ? 37 ++++++++----------------------
> ?1 files changed, 10 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
> b/drivers/net/wireless/rt2x00/rt2800usb.c
> index 3778763..3c4b88c 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -400,10 +400,10 @@ static void rt2800usb_write_tx_desc(struct queue_entry
> *entry,
> ? ? ? ?/*
> ? ? ? ? * The size of TXINFO_W0_USB_DMA_TX_PKT_LEN is
> ? ? ? ? * TXWI + 802.11 header + L2 pad + payload + pad,
> - ? ? ? ?* so need to decrease size of TXINFO and USB end pad.
> + ? ? ? ?* so need to decrease size of TXINFO.
> ? ? ? ? */
> ? ? ? ?rt2x00_set_field32(&word, TXINFO_W0_USB_DMA_TX_PKT_LEN,
> - ? ? ? ? ? ? ? ? ? ? ? ? ?entry->skb->len - TXINFO_DESC_SIZE - 4);
> + ? ? ? ? ? ? ? ? ? ? ? ? ?roundup(entry->skb->len, 4) - TXINFO_DESC_SIZE);
> ? ? ? ?rt2x00_set_field32(&word, TXINFO_W0_WIV,
> ? ? ? ? ? ? ? ? ? ? ? ? ? !test_bit(ENTRY_TXD_ENCRYPT_IV, &txdesc->flags));
> ? ? ? ?rt2x00_set_field32(&word, TXINFO_W0_QSEL, 2);
> @@ -421,37 +421,20 @@ static void rt2800usb_write_tx_desc(struct queue_entry
> *entry,
> ? ? ? ?skbdesc->desc_len = TXINFO_DESC_SIZE + TXWI_DESC_SIZE;
> ?}
>
> -static void rt2800usb_write_tx_data(struct queue_entry *entry,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct txentry_desc *txdesc)
> +/*
> + * TX data initialization
> + */
> +static int rt2800usb_get_tx_data_len(struct queue_entry *entry)
> ?{
> - ? ? ? unsigned int len;
> - ? ? ? int err;
> -
> - ? ? ? rt2800_write_tx_data(entry, txdesc);
> -
> ? ? ? ?/*
> - ? ? ? ?* pad(1~3 bytes) is added after each 802.11 payload.
> - ? ? ? ?* USB end pad(4 bytes) is added at each USB bulk out packet end.
> + ? ? ? ?* pad(1~3 bytes) is needed after each 802.11 payload.
> + ? ? ? ?* USB end pad(4 bytes) is needed at each USB bulk out packet end.
> ? ? ? ? * TX frame format is :
> ? ? ? ? * | TXINFO | TXWI | 802.11 header | L2 pad | payload | pad | USB end
> pad |
> ? ? ? ? * ? ? ? ? ? ? ? ? |<------------- tx_pkt_len ------------->|
> ? ? ? ? */
> - ? ? ? len = roundup(entry->skb->len, 4) + 4;
> - ? ? ? err = skb_padto(entry->skb, len);
> - ? ? ? if (unlikely(err)) {
> - ? ? ? ? ? ? ? WARNING(entry->queue->rt2x00dev, "TX SKB padding error, out
> of memory\n");
> - ? ? ? ? ? ? ? return;
> - ? ? ? }
>
> - ? ? ? entry->skb->len = len;
> -}
> -
> -/*
> - * TX data initialization
> - */
> -static int rt2800usb_get_tx_data_len(struct queue_entry *entry)
> -{
> - ? ? ? return entry->skb->len;
> + ? ? ? return roundup(entry->skb->len, 4) + 4;
So, you're returning a len that is bigger then the actual size of the skb?
Helmut
------------------------------
Message: 2
Date: Thu, 22 Dec 2011 09:46:32 +0100
From: Helmut Schaa <[email protected]>
To: Jakub Kici?ski <[email protected]>
Cc: [email protected]
Subject: Re: [rt2x00-users] [PATCH] rt2x00usb: Zero USB padding before
sending URB
Message-ID:
<CAGXE3d_WtyWNSmP3yvN=cmgymkly4uy7zwr2ny_eughqrxf...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
2011/12/21 Jakub Kici?ski <[email protected]>:
> When USB driver requires padding at the end of frame or URB it will report
> this need by increasing return value of get_tx_data_len callback. Common
> USB code uses that return value as desired URB length.
>
> Ensure that appropriate part of skb's tailroom exists and is zeroed.
>
>
> Signed-off-by: Jakub Kicinski <[email protected]>
> --
> ?drivers/net/wireless/rt2x00/rt2x00usb.c | ? 16 +++++++++++++---
> ?1 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c
> b/drivers/net/wireless/rt2x00/rt2x00usb.c
> index 1e31050..2eea386 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
> @@ -298,12 +298,22 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry
> *entry, void* data)
> ? ? ? ? ? ? ? ?return false;
>
> ? ? ? ?/*
> - ? ? ? ?* USB devices cannot blindly pass the skb->len as the
> - ? ? ? ?* length of the data to usb_fill_bulk_urb. Pass the skb
> - ? ? ? ?* to the driver to determine what the length should be.
> + ? ? ? ?* USB devices require certain padding at the end of each frame
> + ? ? ? ?* and urb. Those paddings are not included in skbs. Pass entry
> + ? ? ? ?* to the driver to determine what the overall length should be.
> ? ? ? ? */
> ? ? ? ?length = rt2x00dev->ops->lib->get_tx_data_len(entry);
>
> + ? ? ? status = skb_padto(entry->skb, length);
> + ? ? ? if (unlikely(status)) {
> + ? ? ? ? ? ? ? /* TODO: report something more appropriate than IO_FAILED. */
> + ? ? ? ? ? ? ? WARNING(rt2x00dev, "TX SKB padding error, out of memory\n");
> + ? ? ? ? ? ? ? set_bit(ENTRY_DATA_IO_FAILED, &entry->flags);
> + ? ? ? ? ? ? ? rt2x00lib_dmadone(entry);
> +
> + ? ? ? ? ? ? ? return false;
> + ? ? ? }
> +
That's what I was looking for in the first patch.
> ? ? ? ?usb_fill_bulk_urb(entry_priv->urb, usb_dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ?usb_sndbulkpipe(usb_dev, entry->queue->usb_endpoint),
> ? ? ? ? ? ? ? ? ? ? ? ? ?entry->skb->data, length,
Helmut
------------------------------
Message: 3
Date: Thu, 22 Dec 2011 10:48:55 +0100
From: Jakub Kici?ski <[email protected]>
To: Helmut Schaa <[email protected]>
Cc: [email protected]
Subject: Re: [rt2x00-users] [PATCH] rt2800usb: Let rt2x00usb handle
USB padding
Message-ID: <20111222104855.0e1fe358@north>
Content-Type: text/plain; charset=UTF-8
Hi,
On Thu, 22 Dec 2011 09:44:39 +0100
Helmut Schaa <[email protected]> wrote:
> Hi,
>
> 2011/12/21 Jakub Kici?ski <[email protected]>:
> > Older USB drivers does not append end padding to skb but instead report
> > it in size of data to be transmitted to HW. rt2800usb should follow that
> > behaviour. Custom write_tx_data callback which was adding pad to skb
> > is not be needed any more.
> >
> > Thanks to this patch frames handed back from rt2800usb to mac80211 will
> > no longer contain end padding.
> >
> >
> > Signed-off-by: Jakub Kicinski <[email protected]>
> > ---
> > ?drivers/net/wireless/rt2x00/rt2800usb.c | ? 37
> > ++++++++----------------------
> > ?1 files changed, 10 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
> > b/drivers/net/wireless/rt2x00/rt2800usb.c
> > index 3778763..3c4b88c 100644
> > --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> > +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> > @@ -400,10 +400,10 @@ static void rt2800usb_write_tx_desc(struct
> > queue_entry *entry,
> > ? ? ? ?/*
> > ? ? ? ? * The size of TXINFO_W0_USB_DMA_TX_PKT_LEN is
> > ? ? ? ? * TXWI + 802.11 header + L2 pad + payload + pad,
> > - ? ? ? ?* so need to decrease size of TXINFO and USB end pad.
> > + ? ? ? ?* so need to decrease size of TXINFO.
> > ? ? ? ? */
> > ? ? ? ?rt2x00_set_field32(&word, TXINFO_W0_USB_DMA_TX_PKT_LEN,
> > - ? ? ? ? ? ? ? ? ? ? ? ? ?entry->skb->len - TXINFO_DESC_SIZE - 4);
> > + ? ? ? ? ? ? ? ? ? ? ? ? ?roundup(entry->skb->len, 4) - TXINFO_DESC_SIZE);
> > ? ? ? ?rt2x00_set_field32(&word, TXINFO_W0_WIV,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? !test_bit(ENTRY_TXD_ENCRYPT_IV, &txdesc->flags));
> > ? ? ? ?rt2x00_set_field32(&word, TXINFO_W0_QSEL, 2);
> > @@ -421,37 +421,20 @@ static void rt2800usb_write_tx_desc(struct
> > queue_entry *entry,
> > ? ? ? ?skbdesc->desc_len = TXINFO_DESC_SIZE + TXWI_DESC_SIZE;
> > ?}
> >
> > -static void rt2800usb_write_tx_data(struct queue_entry *entry,
> > - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct txentry_desc *txdesc)
> > +/*
> > + * TX data initialization
> > + */
> > +static int rt2800usb_get_tx_data_len(struct queue_entry *entry)
> > ?{
> > - ? ? ? unsigned int len;
> > - ? ? ? int err;
> > -
> > - ? ? ? rt2800_write_tx_data(entry, txdesc);
> > -
> > ? ? ? ?/*
> > - ? ? ? ?* pad(1~3 bytes) is added after each 802.11 payload.
> > - ? ? ? ?* USB end pad(4 bytes) is added at each USB bulk out packet end.
> > + ? ? ? ?* pad(1~3 bytes) is needed after each 802.11 payload.
> > + ? ? ? ?* USB end pad(4 bytes) is needed at each USB bulk out packet end.
> > ? ? ? ? * TX frame format is :
> > ? ? ? ? * | TXINFO | TXWI | 802.11 header | L2 pad | payload | pad | USB
> > end pad |
> > ? ? ? ? * ? ? ? ? ? ? ? ? |<------------- tx_pkt_len ------------->|
> > ? ? ? ? */
> > - ? ? ? len = roundup(entry->skb->len, 4) + 4;
> > - ? ? ? err = skb_padto(entry->skb, len);
> > - ? ? ? if (unlikely(err)) {
> > - ? ? ? ? ? ? ? WARNING(entry->queue->rt2x00dev, "TX SKB padding error, out
> > of memory\n");
> > - ? ? ? ? ? ? ? return;
> > - ? ? ? }
> >
> > - ? ? ? entry->skb->len = len;
> > -}
> > -
> > -/*
> > - * TX data initialization
> > - */
> > -static int rt2800usb_get_tx_data_len(struct queue_entry *entry)
> > -{
> > - ? ? ? return entry->skb->len;
> > + ? ? ? return roundup(entry->skb->len, 4) + 4;
>
> So, you're returning a len that is bigger then the actual size of the skb?
Yes, that's what rt73usb and rt2500usb are doing. get_tx_data_len is
used only in rt2x00usb_kick_tx_entry to determine overall length of URB
to be submitted to HW. The name may be a little unfortunate, could be
something like get_tx_dma_len.
-- Kuba
------------------------------
Message: 4
Date: Thu, 22 Dec 2011 15:35:58 +0200
From: Daniel Golle <[email protected]>
To: "[email protected]" <[email protected]>
Cc: OpenWrt Development List <[email protected]>
Subject: [rt2x00-users] rt2880 AP performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
I'm trying to run an HT40-enabled AP using the rt2880 mac80211 driver on OpenWrt
running on an Rt3050 SoC.
Somehow, the performance doesn't differ no matter if HT40 is enabled or not.
Though the nominal bitrate shown in iwconfig is 72.2MBit/s for HT20 and
150MBit/s for HT40+/-, the TCP throughput in both cases if around 26MBit/s
(which is more or less satisfying for 20MHz, but should be twice as much for
40MHz).
What performance did you experience when using rt2880 in AP mode?
Did anyone ever get greenfield 40MHz working in 2.4GHz between two identical
rt2880 devices? If so, how did you do that?
Details of my setup follow:
system type: Ralink RT3350 id:1 rev:2
rt chip: 2872
rf chip: 0005
revision: 0200
register base words wordsize
csr 4096 512 4
eeprom 0 136 2
bbp 0 128 1
rf 4 4 4
I'm using kernel 2.6.39.4, compat-wireless-2011-12-01, hostapd-2.0 (20111103).
Newer versions of hostapd don't even seem to announce HT40 at all, so the
nominal rate doesn't ever exceed 72.2MBit when using newer versions of hostapd.
hostapd.conf looks like this:
- ------------------------------
ctrl_interface=/var/run/hostapd-phy0
driver=nl80211
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5
hw_mode=g
channel=11
noscan=1
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
ieee80211n=1
ht_capab=[HT40-][GF][SHORT-GI-20][SHORT-GI-40][RX-STBC1]
interface=wlan0
ctrl_interface=/var/run/hostapd-phy0
auth_algs=1
wpa=0
ssid=Allnet
bridge=br-lan
wmm_enabled=1
bssid=48:02:2a:60:21:a4
ignore_broadcast_ssid=0
- ------------------------------
Best regards
Daniel
- --
ALLNET GmbH ; Maistr. 2 ; D-82110 Germering ; Germany
Tel. +49-89-89422222 - Fax +49-89-89422233
http://www.allnet.de
email: Daniel Golle <[email protected]>
Schulungs-/Veranstaltungsprogramm: http://www.802lab.de<http://www.802lab.de/>
Gesch?ftsf?hrer: Wolfgang Marcus Bauer
Handelsregister M?nchen B 95922 ; UST-ID-Nr. DE 128214294 ;
St.-Nr.117/115/00164
WEEE-Reg.-NR. DE 13101093
Bankverbindung:
Sparkasse F?rstenfeldbruck KTO: 2774594 ; BLZ: 70053070
Swift-Code: BYLADEM1FFB ; IBAN: DE61700530700002774594
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJO8zI6AAoJEDy9cKN/1Et08NUP/inJJBWOJr7znl9c5QoJLKy/
UiB2KH0/gdLkLmnycL5IWuMTPPw4KSLz/UCHbErLXOWTNVWOfaUq+V2LlUbd7qJF
6761CKSAaUgthG+yh8OKMo2r1Wu3wpRWRif1l7lLSkuJf9vYwSViww+WGtdLr3Qn
HfVIvxyMkZKjxxVO4v8r3Qd8Ubn/Rn8sOM8mWjXqa7KtgLXkWM5Vwtik3UBhLQkH
XMncRs414TKCLwm2i2B3Hx7GjwyDe8dUvX+9XKJpQ4TDOf52cs63asc9u3fp8lkd
iHlhyUCu+vBzcSZBjg3FOvnKxe26p327Ag/tYL/4w3O6jfQxk+OZAdGveVVoMhMY
gmmlD9zUkDJqxzAAIKdf193u7JE2tLageSoY9KbiC7Q54FdbxB2FDu3y84539/bu
o61cGvFNLyeHklVum37lAbAi7SM6r6rx+PzJq4STc90pV/MffiE4MAL1NkBynCse
mvuCT5mHl8butGRQ4UuLjMLYd2Bzs8nfWDUyZ/tXRVbVLG1wKiLdB+LoZildLzDx
fvNa2thGE5YPDZOvYa9AruB8QLHHYvN+staBmdUvwDMru3mw6JrNAySSpOng0t7X
dK/4e9PnnV5kl8ahl+Bng8vSr9t40MykKhXSOUy0/LPUMf4IPkdY6VCePn/2QldV
wQSjbppQGeIR+KPfXZSL
=vp+Z
-----END PGP SIGNATURE-----
------------------------------
Message: 5
Date: Thu, 22 Dec 2011 16:35:18 +0100
From: Stanislaw Gruszka <[email protected]>
To: Jakub Kici?ski <[email protected]>
Cc: [email protected]
Subject: Re: [rt2x00-users] [PATCH] rt2800usb: Let rt2x00usb handle
USB padding
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On Wed, Dec 21, 2011 at 12:31:49PM +0100, Jakub Kici?ski wrote:
> Older USB drivers does not append end padding to skb but instead report
> it in size of data to be transmitted to HW. rt2800usb should follow that
> behaviour. Custom write_tx_data callback which was adding pad to skb
> is not be needed any more.
>
> Thanks to this patch frames handed back from rt2800usb to mac80211 will
> no longer contain end padding.
>
>
> Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
------------------------------
Message: 6
Date: Thu, 22 Dec 2011 16:33:29 +0100
From: Stanislaw Gruszka <[email protected]>
To: Jakub Kici?ski <[email protected]>
Cc: [email protected]
Subject: Re: [rt2x00-users] [PATCH] rt2x00usb: Zero USB padding before
sending URB
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On Wed, Dec 21, 2011 at 12:31:49PM +0100, Jakub Kici?ski wrote:
> When USB driver requires padding at the end of frame or URB it will report
> this need by increasing return value of get_tx_data_len callback. Common
> USB code uses that return value as desired URB length.
>
> Ensure that appropriate part of skb's tailroom exists and is zeroed.
>
>
> Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
------------------------------
Message: 7
Date: Thu, 22 Dec 2011 17:18:28 +0100
From: Stanislaw Gruszka <[email protected]>
To: Robert Hancock <[email protected]>
Cc: Andreas Hartmann <[email protected]>, linux-wireless
<[email protected]>, linux-kernel
<[email protected]>, [email protected]
Subject: Re: [rt2x00-users] Poor performance and lockup with rt2800usb
and Asus USB-N13 adapter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Tue, Dec 20, 2011 at 03:43:17PM +0100, Stanislaw Gruszka wrote:
> I just discovered that at least some problems are related with power
> save. After "iwconfig wlanX power off" I have pretty short ping times
> and good throughput, both comparable with vendor driver. But I did not
> check that on all adapters that I have yet.
>
> Looking a bit more at that seem we stop and wake queues several times
> between sending each frame. Looks like that thing need to be optimized
> in mac80211, or some parameters have to be setup properly by rt2x00 ...
>
> Also rt2800 PCI and SOC have PS disabled by default ...
There is no bug with ping latencies when power save is enabled. Ping
send packet every second, between that we put driver in power save
mode (i.e. tell AP that we are sleeping and it has to buffer frame
to us). When we send ping packet, we wake up and receive packet from
a AP after longer time than in normal operation mode.
I did more testing here and I have one device that works very bad,
no matter if PS is configured or not. It is
phy6 -> rt2x00_set_chip: Info - Chipset detected - rt: 3071, rf: 0008, rev:
021c.
I'm going to investigate problems with that device, hopefully these are the
same problems that Robert and Andreas have.
Stanislaw
------------------------------
_______________________________________________
users mailing list
[email protected]
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
End of users Digest, Vol 34, Issue 10
*************************************
