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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
