From: Seth Forshee <seth.forshee@canonical.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, Stanislaw Gruszka <sgruszka@redhat.com>
Subject: Re: [PATCH v3 1/2] mac80211: Fix tx queue handling during scans
Date: Fri, 8 Feb 2013 12:10:02 -0600 [thread overview]
Message-ID: <20130208181002.GD2622@thinkpad-t410> (raw)
In-Reply-To: <1360343852.29851.26.camel@jlt4.sipsolutions.net>
On Fri, Feb 08, 2013 at 06:17:32PM +0100, Johannes Berg wrote:
> On Fri, 2013-02-08 at 11:11 -0600, Seth Forshee wrote:
>
> > > I started wondering -- is there a reason to modify the entire TX path?
> > > Could we maybe bypass it instead and call the driver's TX op almost
> > > directly? The frames in question don't really need much TX handling, the
> > > only thing that might be relevant _could_ be rate control but even that
> > > I'd argue isn't really needed, just using rate_control_send_low() should
> > > be ok (by setting IEEE80211_TX_CTL_USE_MINRATE it will always return
> > > true). For the null data packets the sta pointer is also obvious, the AP
> > > station (BSSID) ... we don't need any of the extra monitor/whatever
> > > handling either.
> > >
> > > That might be simpler overall?
> >
> > Okay, I'll take a look at this.
> >
> > Another option that might simplify things a bit would be to use a
> > ieee80211_tx_data flag. If I added another interface into tx.c for
> > offchannel frames then the offchan argument would only be needed for
> > ieee80211_xmit() and ieee80211_tx(). Though it would be nice to avoid
> > adding an argument to ieee80211_xmit().
This actually doesn't work out. ieee80211_tx_data doesn't propogate down
to ieee80211_tx_frags() and isn't even there in the txpending case. So
without more substantial changes it just turns back into an argument
after a couple of levels.
> Oh, I forgot all about ROC and off-channel frames there, but those are
> public action frames (only?) so the same applies with min-rate etc.
I thought of that and was going to check and see what kind of ROC frames
are sent. Also probe request frames are obviously sent off-channel, but
I'd guess the same applies to them as well?
> Overall I'm not sure. On the one hand that might make the code changes
> simpler, on the other it might make the code more complex?
Well, I think the way that will be simplest with the fewest code changes
would be to use a tx control flag. Of course then we've gobbled up one
of the last available flags.
Seth
next prev parent reply other threads:[~2013-02-08 18:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 15:01 [PATCH 0/4] Improve queue handling for off-channel operation Seth Forshee
2013-02-06 15:01 ` [PATCH 1/4] mac80211: Return a status for tx operations Seth Forshee
2013-02-06 15:01 ` [PATCH 2/4] mac80211: Fix tx queue handling during scans Seth Forshee
2013-02-06 15:01 ` [PATCH 3/4] mac80211: Improve error handling for off-channel operation Seth Forshee
2013-02-06 21:44 ` Johannes Berg
2013-02-06 22:05 ` Seth Forshee
2013-02-06 22:10 ` Johannes Berg
2013-02-06 22:20 ` Seth Forshee
2013-02-06 22:26 ` Johannes Berg
2013-02-06 22:30 ` Johannes Berg
2013-02-07 17:54 ` [PATCH v3 1/2] mac80211: Fix tx queue handling during scans Seth Forshee
2013-02-07 17:54 ` [PATCH v3 2/2] mac80211: Add flushes before going off-channel Seth Forshee
2013-02-08 9:03 ` [PATCH v3 1/2] mac80211: Fix tx queue handling during scans Johannes Berg
2013-02-08 17:11 ` Seth Forshee
2013-02-08 17:17 ` Johannes Berg
2013-02-08 18:10 ` Seth Forshee [this message]
2013-02-08 19:05 ` Johannes Berg
2013-02-08 20:46 ` Seth Forshee
2013-02-08 20:53 ` Johannes Berg
2013-02-11 17:18 ` Seth Forshee
2013-02-11 17:21 ` [PATCH v4 " Seth Forshee
2013-02-11 17:21 ` [PATCH v4 2/2] mac80211: Add flushes before going off-channel Seth Forshee
2013-02-11 21:40 ` [PATCH v4 1/2] mac80211: Fix tx queue handling during scans Johannes Berg
2013-02-11 21:50 ` Seth Forshee
2013-02-06 15:01 ` [PATCH 4/4] mac80211: Add flushes before going off-channel Seth Forshee
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=20130208181002.GD2622@thinkpad-t410 \
--to=seth.forshee@canonical.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=sgruszka@redhat.com \
/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.