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@xxxxxxxxxxxxxxx wrote:
> >>From: Ben Greear<greearb@xxxxxxxxxxxxxxx>
> >>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
--
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
