From: Ben Greear <greearb@candelatech.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH] ath9k: Implement rx copy-break.
Date: Sat, 08 Jan 2011 17:06:52 -0800 [thread overview]
Message-ID: <4D290A2C.6040803@candelatech.com> (raw)
In-Reply-To: <4D290450.8070700@openwrt.org>
On 01/08/2011 04:41 PM, Felix Fietkau wrote:
> On 2011-01-08 5:36 PM, Ben Greear wrote:
>> On 01/08/2011 04:20 PM, Felix Fietkau wrote:
>>> I think this should be dependent on packet size, maybe even based on the architecture. Especially on embedded hardware, copying large frames is probably quite a
>>> bit more expensive than allocating large buffers. Cache sizes are small, memory access takes several cycles, especially during concurrent DMA.
>>> Once I'm back home, I could try a few packet size threshold to find a sweet spot for the typical MIPS hardware that I'm playing with. I expect a visible
>>> performance regression from this patch when applied as-is.
>>
>> 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).
>>
>> If we do see performance differences on different platforms, this could perhaps be
>> something we could tune at run-time.
> What kind of system are you testing on? If it's a PC, then the performance characteristics will be completely different compared to embedded hardware. I've had
> to remove a few copybreak-like implementations from various ethernet drivers on similar hardware, because even taking the hit of unaligned load/store exceptions
> (which are already *very* expensive on MIPS) was less than copying the full packet data, even with packet sizes less than what you're using.
>
> I don't have suitable test hardware with me right now, but I'll do some tests in a week or so.
I'm on a dual-core Atom processor. I'm interested in your MIPs results when you get them...
Thanks,
Ben
>
> - Felix
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb@candelatech.com>
To: Felix Fietkau <nbd@openwrt.org>
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
Subject: Re: [PATCH] ath9k: Implement rx copy-break.
Date: Sat, 08 Jan 2011 17:06:52 -0800 [thread overview]
Message-ID: <4D290A2C.6040803@candelatech.com> (raw)
In-Reply-To: <4D290450.8070700@openwrt.org>
On 01/08/2011 04:41 PM, Felix Fietkau wrote:
> On 2011-01-08 5:36 PM, Ben Greear wrote:
>> On 01/08/2011 04:20 PM, Felix Fietkau wrote:
>>> I think this should be dependent on packet size, maybe even based on the architecture. Especially on embedded hardware, copying large frames is probably quite a
>>> bit more expensive than allocating large buffers. Cache sizes are small, memory access takes several cycles, especially during concurrent DMA.
>>> Once I'm back home, I could try a few packet size threshold to find a sweet spot for the typical MIPS hardware that I'm playing with. I expect a visible
>>> performance regression from this patch when applied as-is.
>>
>> 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).
>>
>> If we do see performance differences on different platforms, this could perhaps be
>> something we could tune at run-time.
> What kind of system are you testing on? If it's a PC, then the performance characteristics will be completely different compared to embedded hardware. I've had
> to remove a few copybreak-like implementations from various ethernet drivers on similar hardware, because even taking the hit of unaligned load/store exceptions
> (which are already *very* expensive on MIPS) was less than copying the full packet data, even with packet sizes less than what you're using.
>
> I don't have suitable test hardware with me right now, but I'll do some tests in a week or so.
I'm on a dual-core Atom processor. I'm interested in your MIPs results when you get them...
Thanks,
Ben
>
> - Felix
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2011-01-09 1:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-08 15:33 [ath9k-devel] [PATCH] ath9k: Implement rx copy-break greearb at candelatech.com
2011-01-08 15:33 ` greearb
2011-01-09 0:20 ` [ath9k-devel] " Felix Fietkau
2011-01-09 0:20 ` Felix Fietkau
2011-01-09 0:36 ` [ath9k-devel] " Ben Greear
2011-01-09 0:36 ` Ben Greear
2011-01-09 0:41 ` [ath9k-devel] " Felix Fietkau
2011-01-09 0:41 ` Felix Fietkau
2011-01-09 1:06 ` Ben Greear [this message]
2011-01-09 1:06 ` Ben Greear
2011-01-09 14:15 ` [ath9k-devel] " Björn Smedman
2011-01-09 14:15 ` Björn Smedman
2011-01-09 14:18 ` [ath9k-devel] " Felix Fietkau
2011-01-09 14:18 ` Felix Fietkau
2011-01-09 15:35 ` [ath9k-devel] " Björn Smedman
2011-01-09 15:35 ` Björn Smedman
2011-01-09 18:13 ` [ath9k-devel] " Jouni Malinen
2011-01-09 18:13 ` Jouni Malinen
2011-01-09 20:14 ` [ath9k-devel] " Christian Lamparter
2011-01-09 20:14 ` Christian Lamparter
2011-01-09 20:24 ` [ath9k-devel] " Felix Fietkau
2011-01-09 20:24 ` Felix Fietkau
2011-01-10 12:40 ` [ath9k-devel] " Jouni Malinen
2011-01-10 12:40 ` Jouni Malinen
2011-01-10 4:32 ` [ath9k-devel] " Ben Greear
2011-01-10 4:32 ` Ben Greear
2011-01-09 8:00 ` [ath9k-devel] " Gabor Juhos
2011-01-09 8:00 ` Gabor Juhos
2011-01-09 17:49 ` [ath9k-devel] " Ben Greear
2011-01-09 17:49 ` Ben Greear
2011-01-10 7:14 ` [ath9k-devel] " Gabor Juhos
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=4D290A2C.6040803@candelatech.com \
--to=greearb@candelatech.com \
--cc=ath9k-devel@lists.ath9k.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.