I am looking for ideas how can one process AMSDU in the software, without copying data.
Current implementation like ieee80211_amsdu_to_8023s() do copy packet data.
Assume I got in the driver, MPDU that is AMSDU containing several MSDU's.
It is in the single memory buffer that was allocated for DMA.
Can I construct skb's per MSDU with minimal data copy, having most of the
original data in place? Any ideas for this?
Thanks, Vladimir.
On Thu, Feb 19, 2015 at 12:51 PM, Vladimir Kondratiev
<[email protected]> wrote:
>
> I am looking for ideas how can one process AMSDU in the software, without copying data.
> Current implementation like ieee80211_amsdu_to_8023s() do copy packet data.
>
> Assume I got in the driver, MPDU that is AMSDU containing several MSDU's.
> It is in the single memory buffer that was allocated for DMA.
> Can I construct skb's per MSDU with minimal data copy, having most of the
> original data in place? Any ideas for this?
>
You already have the TCP header inside the MSDUs. I guess all you need
to do is to clone the skb and update the offset in the frag?
Note that tn that case, the page will be shared. I am really not an
expert in all this kind of things.
Note that iwlwifi can technically have 2 Rx packets in the same page,
we handle that.
> Thanks, Vladimir.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, February 23, 2015 09:35:39 AM Johannes Berg wrote:
> If the SKB has pages (rather than being linear, as
> ieee80211_amsdu_to_8023s() assumes) then what Emmanuel said would
> probably be the best approach, although it could be possible that would
> mess up truesize accounting and lead to lower performance. Certainly
> you'd want to do it only for suitably large packets (at least bigger
> than 128 bytes or so)
Why is it important whether it has pages? Looks like I can play with
pointers to the linear part as well.
I am thinking about the following scenario: in DMG (60G), max. MSDU size
is 7920, so one have to account for this when establishing BACK. Then,
I foresee it will be popular that MTU will be configured to 1500 (Ethernet
bridging, just laziness etc.), so actual aggregations on the air would be 5x
smaller that it could be. Then, I'd like to aggregate 5 packets 1500 bytes
each into A-MSDU prior to aggregating it to A_MPDU. Then, I'll have
good A-MPDU size. But, having more then 2Gbps throughput, I need
effective way to de-aggregate A-MSDU on Rx side.
Thanks, Vladimir
On Wed, 2015-02-25 at 09:07 +0200, Vladimir Kondratiev wrote:
> On Monday, February 23, 2015 09:35:39 AM Johannes Berg wrote:
> > If the SKB has pages (rather than being linear, as
> > ieee80211_amsdu_to_8023s() assumes) then what Emmanuel said would
> > probably be the best approach, although it could be possible that would
> > mess up truesize accounting and lead to lower performance. Certainly
> > you'd want to do it only for suitably large packets (at least bigger
> > than 128 bytes or so)
>
> Why is it important whether it has pages? Looks like I can play with
> pointers to the linear part as well.
I don't think that will work - it would crash later trying to free that
page, no?
Oh - you mean just skb_pull() and friends? That might actually work,
yeah.
johannes
On Thu, 2015-02-19 at 12:51 +0200, Vladimir Kondratiev wrote:
> I am looking for ideas how can one process AMSDU in the software, without copying data.
> Current implementation like ieee80211_amsdu_to_8023s() do copy packet data.
>
> Assume I got in the driver, MPDU that is AMSDU containing several MSDU's.
> It is in the single memory buffer that was allocated for DMA.
> Can I construct skb's per MSDU with minimal data copy, having most of the
> original data in place? Any ideas for this?
As you noticed, this implementation is very inefficient.
If the SKB has pages (rather than being linear, as
ieee80211_amsdu_to_8023s() assumes) then what Emmanuel said would
probably be the best approach, although it could be possible that would
mess up truesize accounting and lead to lower performance. Certainly
you'd want to do it only for suitably large packets (at least bigger
than 128 bytes or so)
johannes