From: Jouni Malinen <j@w1.fi>
To: Ben Greear <greearb@candelatech.com>
Cc: Felix Fietkau <nbd@openwrt.org>,
linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
Subject: Re: [PATCH] ath9k: Implement rx copy-break.
Date: Sun, 9 Jan 2011 20:13:04 +0200 [thread overview]
Message-ID: <20110109181303.GA12562@jm.kir.nu> (raw)
In-Reply-To: <4D290307.4080807@candelatech.com>
On Sat, Jan 08, 2011 at 04:36:23PM -0800, Ben Greear wrote:
> On 01/08/2011 04:20 PM, Felix Fietkau wrote:
> >On 2011-01-08 8:33 AM, greearb@candelatech.com wrote:
> >>From: Ben Greear<greearb@candelatech.com>
> >>This saves us constantly allocating large, multi-page
> >>skbs. It should fix the order-1 allocation errors reported,
> >>and in a 60-vif scenario, this significantly decreases CPU
> >>utilization, and latency, and increases bandwidth.
As far as CPU use is concerned, 60 VIF scenario should not be the one to
use for checking what is most efficient.. This really needs to be tested
on something that uses a single VIF on an embedded (low-power CPU)..
For the order-1 allocation issues, it would be interesting to see if
someone could take a look at using paged skbs or multiple RX descriptors
with shorter skbs (and copying only for the case where a long frame is
received so that only the A-MSDU RX case would suffer from extra
copying).
> I see a serious performance improvement with this patch. My current test is sending 1024 byte UDP
> payloads to/from each of 60 stations at 128kbps. Please do try it out on your system and see how
> it performs there. I'm guessing that any time you have more than 1 VIF this will be a good
> improvement since mac80211 does skb_copy (and you would typically be copying a much smaller
> packet with this patch).
How would this patch change the number of bytes copied by skb_copy?
> If we do see performance differences on different platforms, this could perhaps be
> something we could tune at run-time.
I guess that could be looked at, but as long as that is not the case,
the test setup you used is not exactly the most common case for ath9k in
the upstream kernel and should not be used to figure out default
behavior.
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2011-01-09 18:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-08 15:33 [PATCH] ath9k: Implement rx copy-break greearb
2011-01-09 0:20 ` Felix Fietkau
2011-01-09 0:36 ` Ben Greear
2011-01-09 0:41 ` Felix Fietkau
2011-01-09 1:06 ` Ben Greear
2011-01-09 14:15 ` Björn Smedman
2011-01-09 14:18 ` Felix Fietkau
2011-01-09 15:35 ` Björn Smedman
2011-01-09 18:13 ` Jouni Malinen [this message]
2011-01-09 20:14 ` Christian Lamparter
2011-01-09 20:24 ` Felix Fietkau
2011-01-10 12:40 ` Jouni Malinen
2011-01-10 4:32 ` Ben Greear
2011-01-09 8:00 ` Gabor Juhos
2011-01-09 17:49 ` Ben Greear
2011-01-10 7:14 ` Gabor Juhos
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=20110109181303.GA12562@jm.kir.nu \
--to=j@w1.fi \
--cc=ath9k-devel@venema.h4ckr.net \
--cc=greearb@candelatech.com \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@openwrt.org \
/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).