On Sun, Jan 9, 2011 at 2:06 AM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > 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... I think we should also consider the added stability/saneness with this patch. I for one would be willing to live with some extra cpu load if that means the unstoppable rx dma problem can be contained (all the time). Perhaps make it a configuration option? /Björn -- 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
