From: Gertjan van Wingerde <gwingerde@gmail.com>
To: RA-Jay Hung <Jay_Hung@ralinktech.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>,
"John W. Linville" <linville@tuxdriver.com>,
Ivo van Doorn <ivdoorn@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"users@rt2x00.serialmonkey.com" <users@rt2x00.serialmonkey.com>
Subject: Re: [PATCH 9/9] rt2x00: Modify rt2x00queue_remove_l2pad to make skb->data two-byte alignment
Date: Mon, 22 Nov 2010 11:05:14 +0100 [thread overview]
Message-ID: <AANLkTimYWLMgQ_RNZJ5B6a-vA68ez1Wcc702MrdS0QzW@mail.gmail.com> (raw)
In-Reply-To: <B7288B2B5878D747BA031EF4B170D7F6BC824E@TWHCMBS01.tw.ralinktech.ad>
On Mon, Nov 22, 2010 at 9:14 AM, RA-Jay Hung <Jay_Hung@ralinktech.com> wrote:
> Hi,
>> > Jay, could you please run a few more performance tests with and without this
>> > patch to track down if this issue is really the cause for the performance
>> > degradation?
>
> I check sniffer and mac80211 code, I think bad TX throughput should be my environment has a lot APs and more packets will collides because of without protection in TX direction. So the patch is not related to this issue. Helmut,
> We can revert this patch. Sorry for inconvenience.
>
>> >> Basic idea is to no longer work on the original skb that mac80211
>> >> supplied us, but to
>> >> use a copy of that skb. This would prevent us from having to undo any
>> >> changes we did,
>> >> as we can simply return the original skb to mac80211 (which wasn't
>> >> modified in the first
>> >> place).
>> >> I'm not sure how this would impact performance, but it would allow us
>> >> a lot less copying
>> >> around to undo the changes done before uploading to the HW.
>> >
>> > But cloning the skb would double the amount of memory needed to transmit each
>> > frame. Not sure though if that behaves better or not. Might be worth a try.
>> >
>> >> However, I won't be able to look into that opportunity before the weekend.
>> >>
>> >> Helmut, can you wait that long and hold off reverting until then?
>> >
>>
>> OK. Find attached the patch I cooked up. AFAICS the driver still works correctly,
>> but unfortunately I am unable to test performance and throughput of the driver
>> with this patch.
>>
>> Jay and Helmut, can you test this patch before I submit it?
>>
> I think original code should recover the original skb state, so I think we do not need to copy again to send back to mac80211, and one more thing. Could you submit below
> patch you send us before to rt2x00.git. I think it is more correct in payload = 0 case.
>
> void rt2x00queue_remove_l2pad(struct sk_buff *skb, unsigned int header_length)
> {
> - unsigned int l2pad = L2PAD_SIZE(header_length);
> + unsigned int payload_length = skb->len - header_length;
> + unsigned int l2pad = payload_length ? L2PAD_SIZE(header_length) : 0;
>
> if (!l2pad)
> return;
>
OK. Indeed if you feel we can simply revert the patch then that will
be better. I'll send a patch tonight that reverts it together with the
update update.
---
Gertjan
next prev parent reply other threads:[~2010-11-22 10:05 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-13 18:08 [PATCH 1/9] rt2x00: Increase REGISTER_BUSY_COUNT Ivo van Doorn
2010-11-13 18:09 ` [PATCH 2/9] rt2x00: Add initial support for RT3370/RT3390 devices Ivo van Doorn
2010-11-13 18:10 ` [PATCH 3/9] rt2x00: Clean up Kconfig for RT2800 devices Ivo van Doorn
2010-11-13 18:10 ` [PATCH 4/9] rt2x00: Remove RT30XX Kconfig variables Ivo van Doorn
2010-11-13 18:10 ` [PATCH 5/9] rt2x00: Remove unneccessary internal Kconfig symbols Ivo van Doorn
2010-11-13 18:11 ` [PATCH 6/9] rt2x00: Use ioremap for SoC devices instead of KSEG1ADDR Ivo van Doorn
2010-11-13 18:11 ` [PATCH 7/9] rt2x00: Fix rt2800 USB TX Path DMA issue Ivo van Doorn
2010-11-13 18:12 ` [PATCH 8/9] rt2x00: Fix header_length in rt2x00lib_txdone Ivo van Doorn
2010-11-13 18:13 ` [PATCH 9/9] rt2x00: Modify rt2x00queue_remove_l2pad to make skb->data two-byte alignment Ivo van Doorn
2010-11-16 15:45 ` Helmut Schaa
2010-11-17 8:46 ` Helmut Schaa
2010-11-17 10:16 ` RA-Jay Hung
2010-11-17 10:48 ` Helmut Schaa
2010-11-17 15:07 ` John W. Linville
2010-11-17 15:34 ` Gertjan van Wingerde
2010-11-17 16:41 ` Helmut Schaa
2010-11-18 1:47 ` [rt2x00-users] " David Ellingsworth
2010-11-22 7:00 ` Gertjan van Wingerde
2010-11-22 8:14 ` RA-Jay Hung
2010-11-22 10:05 ` Gertjan van Wingerde [this message]
2010-11-22 10:22 ` Helmut Schaa
2010-11-16 15:36 ` [PATCH 8/9] rt2x00: Fix header_length in rt2x00lib_txdone Helmut Schaa
2010-11-15 9:45 ` [PATCH 7/9] rt2x00: Fix rt2800 USB TX Path DMA issue Walter Goldens
2010-11-16 1:59 ` RA-Jay Hung
2010-11-16 15:59 ` Johannes Stezenbach
2010-11-16 16:11 ` Helmut Schaa
2010-11-16 16:34 ` Johannes Stezenbach
2010-11-16 16:42 ` Helmut Schaa
2010-11-16 16:53 ` Johannes Stezenbach
2010-11-16 17:00 ` Helmut Schaa
[not found] ` <AANLkTi=ANfE3s8RUmS5=qyofqHM2geRnatK-eCUjovEc@mail.gmail.com>
2010-11-16 19:06 ` Johannes Stezenbach
2010-11-16 19:23 ` Ivo Van Doorn
2010-11-16 19:26 ` Johannes Berg
2010-11-16 19:33 ` Ivo Van Doorn
2010-11-14 8:59 ` [PATCH 3/9] rt2x00: Clean up Kconfig for RT2800 devices Julian Calaby
2010-11-14 9:00 ` Julian Calaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimYWLMgQ_RNZJ5B6a-vA68ez1Wcc702MrdS0QzW@mail.gmail.com \
--to=gwingerde@gmail.com \
--cc=Jay_Hung@ralinktech.com \
--cc=helmut.schaa@googlemail.com \
--cc=ivdoorn@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=users@rt2x00.serialmonkey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).