From: Johannes Berg <johannes@sipsolutions.net>
To: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFC] mac80211: support non-data TXQs
Date: Wed, 21 Jun 2017 10:37:00 +0200 [thread overview]
Message-ID: <1498034220.4955.3.camel@sipsolutions.net> (raw)
In-Reply-To: <1498028959.4955.1.camel@sipsolutions.net> (sfid-20170621_090940_331939_95828741)
On Wed, 2017-06-21 at 09:09 +0200, Johannes Berg wrote:
> On Tue, 2017-06-20 at 21:19 -0700, Igor Mitsyanko wrote:
>
> > > - struct ieee80211_txq *txq[IEEE80211_NUM_TIDS];
> > > + struct ieee80211_txq *txq[IEEE80211_NUM_TIDS + 1];
> >
> > Isn't that a little confusing? Wouldn't it be better to have a
> > separate member for non-data txq and name it accordingly
> > (something
> > like txq_nodata).
>
> We do this trick in quite a number of places, so it shouldn't really
> come as a surprise.
>
> > You have to handle it specially in most cases anyway I guess.
> > With this approach you won't have to replace ARRAY_SIZE(sta->txq)
> > by IEEE80211_NUM_TIDS anywhere.
>
> Yeah, that would indeed be a good reason - I didn't realize the
> ARRAY_SIZE() when I originally wrote the patch. And yes, I do need to
> treat it specially - except then if it's separate I also have to
> initialize it separately, so it's a bit of a trade-off.
I changed my mind on changing this, the allocation, initialization and
teardown etc. just gets much more complicated with doing that, needing
special cases in quite a number of places.
johannes
next prev parent reply other threads:[~2017-06-21 8:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 21:03 [RFC] mac80211: support non-data TXQs Johannes Berg
2017-06-20 21:09 ` Johannes Berg
2017-06-21 4:19 ` Igor Mitsyanko
2017-06-21 7:09 ` Johannes Berg
2017-06-21 7:38 ` Igor Mitsyanko
2017-06-21 8:36 ` Johannes Berg
2017-06-21 8:37 ` Johannes Berg [this message]
2017-06-21 8:48 ` Arend van Spriel
2017-06-21 9:14 ` Johannes Berg
2017-06-21 9:24 ` Johannes Berg
2017-06-21 9:45 ` Johannes Berg
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=1498034220.4955.3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=igor.mitsyanko.os@quantenna.com \
--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 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).