From: Tim Shepard <shep@alum.mit.edu>
To: linux-wireless@vger.kernel.org
Cc: michal.kazior@tieto.com, johannes@sipsolutions.net,
netdev@vger.kernel.org, eric.dumazet@gmail.com,
dave.taht@gmail.com, emmanuel.grumbach@intel.com,
nbd@openwrt.org, andrewmcgr@google.com, apenwarr@google.com
Subject: [PATCH RFC/RFT v2 0/2] ath9k: use mac80211 intermediate software queues
Date: Fri, 04 Mar 2016 12:47:39 -0500 [thread overview]
Message-ID: <E1abtpD-00080r-00@www.xplot.org> (raw)
[ v2: fixed compile errors in first patch when config includes
ATH9K_TX99 or ATH9K_CHANNEL_CONTEXT. Also added signed-off-by
to both patches. ]
Here is a patch in two parts to have ath9k make use the new
intermediate queues in mac80211. It seems to work for me, but it
clearly needs more testing.
This should be useful to anyone who wants to try Michal's patch from
last week "mac80211: implement fq_codel for software queuing" as that
patch will not do anything unless you have a mac80211 driver that uses
the new mac80211 intermediate queues and indicates to mac80211 that
it does so by having a non-zero .wake_tx_queue method.
The first patch just renames the struct ath_txq in ath9k to be
struct ath_hwq and the renames the variables and fields holding a
pointer to it to be hwq (instead of txq).
This first patch is IMHO needed because I had an earlier version of
this without renaming ath_txq and it was too mind bending to try and
keep straight which was ath9k's txq (which is per hardware queue)
and what was mac80211 txq (which is per station per tid).
The second patch changes ath9k to use the new mac80211 intermediate
software queues.
I left the existing ath9k software queue mechanisms in place. They
are used by the channel context code in some cases even for non-data
frames, and in any case it seemed like a safer first step to get this
working before removing code. Yes, we should eventually clean this
up once this is tested and we figure out what the right way to do
the clean up. I see little harm in leaving it stay for awhile.
I have not tried any testing with CONFIG_ATH9K_CHANNEL_CONTEXT=y and
I am not even sure what I would need to do to properly exercise that.
Please comment and/or test.
-Tim Shepard
shep@alum.mit.edu
reply other threads:[~2016-03-04 17:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=E1abtpD-00080r-00@www.xplot.org \
--to=shep@alum.mit.edu \
--cc=andrewmcgr@google.com \
--cc=apenwarr@google.com \
--cc=dave.taht@gmail.com \
--cc=emmanuel.grumbach@intel.com \
--cc=eric.dumazet@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.com \
--cc=nbd@openwrt.org \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).