[ath9k-devel] Paged SKBs v/s copybreak.

[ath9k-devel] Paged SKBs v/s copybreak.

[Ben Greear]

Some time back, I posted a patch to implement rx-copybreak for
ath9k.  There were some other alternative patches that implemented
paged skbs.

My patch had at least one real problem in that it needs to handle
arbitrary busses, not just pci.  Seems that wouldn't be too hard
to implement, but I haven't bothered to date.  It has been stable
for several weeks of testing on various pci-e and pci ath9k NICs.

There was also a worry that for more normal use cases a paged skb
approach might be preferred over the skb-copybreak approach.

I, and a few others, liked pure copybreak because it might work
around DMA start/stop issues in ath9k by ensuring that the hardware
never scribbles on packets handed up the stack.  To me, this is
more important than performance, but then again, I have plenty of
CPU resources available on my systems.

So, I am hoping for some guidance from the core ath9k folks.  Should
I attempt to fix my copybreak patch for non pci busses and re-post
it?

Or should someone fix up the paged skb approach?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Paged SKBs v/s copybreak.

[Jouni Malinen]

On Mon, 2011-01-24 at 14:33 -0800, Ben Greear wrote:

> So, I am hoping for some guidance from the core ath9k folks.  Should
> I attempt to fix my copybreak patch for non pci busses and re-post
> it?

My preference would be to use multiple RX buffers to receive long frames
(chain RX descriptors with rs_more). I sent a preliminary patch for
doing that. Unfortunately, I have not had time to complete this and
probably in the near future. However, if someone has time available, it
should be simple to get the initial version into suitable condition
(just add support for the EDMA case where there may extra meta data in
the beginning of the first RX buffer). That should already be enough to
get the patch in and handle skb taking more than a page allocation
issue. As the next step, mac80211 could be optimized to be able to
handle A-MSDU RX without having to re-allocate and copy the received
long buffers.

The main benefit of this approach is that only the really long frames
(A-MSDU RX) would suffer from the need to re-allocate and copy and even
that A-MSDU RX case can be optimized by extending mac80211. In addition,
this should make it easy to take larger A-MSDU size limit into use
without extra cost for throughput reasons in the future.

- Jouni

[ath9k-devel] Paged SKBs v/s copybreak.

[Felix Fietkau]

On 2011-01-24 11:33 PM, Ben Greear wrote:
> Some time back, I posted a patch to implement rx-copybreak for
> ath9k.  There were some other alternative patches that implemented
> paged skbs.
> 
> My patch had at least one real problem in that it needs to handle
> arbitrary busses, not just pci.  Seems that wouldn't be too hard
> to implement, but I haven't bothered to date.  It has been stable
> for several weeks of testing on various pci-e and pci ath9k NICs.
> 
> There was also a worry that for more normal use cases a paged skb
> approach might be preferred over the skb-copybreak approach.
> 
> I, and a few others, liked pure copybreak because it might work
> around DMA start/stop issues in ath9k by ensuring that the hardware
> never scribbles on packets handed up the stack.  To me, this is
> more important than performance, but then again, I have plenty of
> CPU resources available on my systems.
> 
> So, I am hoping for some guidance from the core ath9k folks.  Should
> I attempt to fix my copybreak patch for non pci busses and re-post
> it?
> 
> Or should someone fix up the paged skb approach?
I think finishing Jouni's patch and using that instead of the copybreak
changes is the way to go, as it fixes the order-1 allocations without
unnecessary data copying.

- Felix