From: Felix Fietkau <nbd@openwrt.org>
To: Emmanuel Grumbach <egrumbach@gmail.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC v2] mac80211: add A-MSDU tx support
Date: Sun, 7 Feb 2016 14:21:48 +0100 [thread overview]
Message-ID: <56B744EC.7090803@openwrt.org> (raw)
In-Reply-To: <CANUX_P2PG1Syik6jekU0Qif4gxZparoTJ124W15_oMWcu=ZCRw@mail.gmail.com>
On 2016-02-07 12:56, Emmanuel Grumbach wrote:
>>> well.. Yes, you can't assume that you'll have one descriptor for one
>>> MSDU payload (unless the driver doesn't advertise SG to the
>>> netstack).
>> Okay, please make a suggestion describing the exact kinds of limits you
>> would need for iwlwifi.
>
> Are athX devices able to handle MPDUs with any number of frags? Say if
> you have 30 different physically contiguous fragments, the DMA would
> be able to load all these into one single packet and send it to the
> air?
I think athX devices have no limitations there. I'm not testing this
with atheros devices though - ath9k does not have mac80211
per-sta-per-tid queueing support yet. I'm working with MediaTek MT76x2
chipsets with my mt76 driver, which I will upstream soon.
> iwlwifi currently has the limitation of 20 Transmit Buffers (BTs)
> which I mentioned earlier. I guess it'd be nice if the driver would be
> able to advertise how many fragments it can handle. Then, you'd need
> to stop the A-MSDU building if you'd cross this boundary?
>
> You can look at skb_shinfo(skb)->nr_frags to know how many frags you
> have for each skb. On top of that, you need 1 frag for each subframe
> (subframe header).
I implemented all of your suggestions in RFC v3, let me know if
anything's missing.
- Felix
prev parent reply other threads:[~2016-02-07 13:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 10:41 [RFC v2] mac80211: add A-MSDU tx support Felix Fietkau
2016-02-07 7:25 ` Emmanuel Grumbach
2016-02-07 9:08 ` Felix Fietkau
2016-02-07 10:06 ` Emmanuel Grumbach
2016-02-07 10:22 ` Emmanuel Grumbach
2016-02-07 10:48 ` Felix Fietkau
2016-02-07 11:32 ` Emmanuel Grumbach
2016-02-07 11:49 ` Felix Fietkau
2016-02-07 11:56 ` Emmanuel Grumbach
2016-02-07 13:21 ` Felix Fietkau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B744EC.7090803@openwrt.org \
--to=nbd@openwrt.org \
--cc=egrumbach@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.