From: Felix Fietkau <nbd@openwrt.org>
To: Christian Lamparter <chunkeey@googlemail.com>
Cc: Jouni Malinen <j@w1.fi>, Ben Greear <greearb@candelatech.com>,
linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
Subject: Re: [PATCH] ath9k: Implement rx copy-break.
Date: Sun, 09 Jan 2011 13:24:16 -0700 [thread overview]
Message-ID: <4D2A1970.5080206@openwrt.org> (raw)
In-Reply-To: <201101092114.55534.chunkeey@googlemail.com>
On 2011-01-09 1:14 PM, Christian Lamparter wrote:
> On Sunday 09 January 2011 19:13:04 Jouni Malinen wrote:
>> 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).
>
> Well, here's a shot at paged rx. It'll only work when PAGE_SIZE> buf_size
> (which will be true for most system, I guess)
>
> No idea how to handle EDMA... In fact I don't have any ath9k* solution
> at the moment to test ;), so you better backup your data!
I think paged rx would be quite problematic for performance on embedded
hardware that way. If I read the networking stack correctly, this would
trigger skb_linearize() for network drivers/devices that cannot do
scatter/gather IO when packets are forwarded between interfaces (the
most common use case for OpenWrt).
It might be possible to avoid this by changing the network stack to
bypass the linearize if there is only data in the page attached to the
skb, but I don't know how easy that is to add, nor what corner cases I'd
need to take care of.
- Felix
next prev parent reply other threads:[~2011-01-09 20:24 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
2011-01-09 20:14 ` Christian Lamparter
2011-01-09 20:24 ` Felix Fietkau [this message]
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=4D2A1970.5080206@openwrt.org \
--to=nbd@openwrt.org \
--cc=ath9k-devel@venema.h4ckr.net \
--cc=chunkeey@googlemail.com \
--cc=greearb@candelatech.com \
--cc=j@w1.fi \
--cc=linux-wireless@vger.kernel.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).