From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: mac80211 and multiple RX queues (with RSS hashing)
Date: Tue, 16 Jun 2015 15:28:25 +0200 [thread overview]
Message-ID: <1434461305.2337.26.camel@sipsolutions.net> (raw)
In-Reply-To: <1434097914.2679.37.camel@sipsolutions.net> (sfid-20150612_103201_684238_7222E571)
On Fri, 2015-06-12 at 10:31 +0200, Johannes Berg wrote:
> * It would only support (non-null) data frames, management frames must
> not be
> passed to the new API, but must be passed to the regular
> ieee80211_rx()
> function.
Sorry about the line breaking - not sure how that happened.
Let me recap these points:
> * only real data frames allowed in "MQ RX" API
> * no _irqsafe variant
> * no software crypto
> * no monitor mode (TBD)
This makes no sense, I think I'll leave monitor mode.
> * no defragmentation
> * no client powersave support
> * no mesh, perhaps no IBSS
> * aggregation reorder already done
> * require NAPI struct (TBD)
Another item we might add:
* no TDLS ethertype frames
Those are more control than data, so they shouldn't really go here. It
wouldn't be hard to support them going there, it just introduces race
conditions.
> b) handling AP/GO powersaving clients
> With RSS, we can end up with various races - right now we say TX
> status and RX must be serialized by the driver, but clearly that
> can no longer be guaranteed with multiple RX queues.
I'm just going to ignore this for now and disallow AP mode unless the HW
offload is enabled.
> [also need to check if there are *other* things that require
> serialization]
TBD
> c) aggregation session timeout/reorder timer handling
> There's a single field/timer (for each of this) per session,
> obviously it's
> not a great idea to hit these from multiple CPUs.
The reorder timeout is moot since we require already well-ordered
frames. Therefore, we can't even have it. Driver developers will have to
think about how to implement that though.
The aggregation session timeout handling actually doesn't really change,
just the data structure needs to be 'exploded' into per-queue structures
instead.
> a2) Alternatively, drivers could tell mac80211 before-hand how many
> queues they'll use, pass a queue identifier to mac80211 for each packet
> (e.g. in skb's queue_mapping) and have mac80211 gather per-queue
> statistics that get combined when read. This means allocating separate
> statistics/queue arrays for stations etc. in mac80211, and then using
> u64_stats_update_begin() etc. to get a consistent reading like we do
> with per-cpu netdev stats already (since my fairly recent patch.)
I'm going to go with this one, but block a few things like 'average
signal' and require drivers to implement those if needed.
johannes
prev parent reply other threads:[~2015-06-16 13:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 8:31 mac80211 and multiple RX queues (with RSS hashing) Johannes Berg
2015-06-16 13:28 ` Johannes Berg [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=1434461305.2337.26.camel@sipsolutions.net \
--to=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.