linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Ben Greear <greearb@candelatech.com>, linux-wireless@vger.kernel.org
Cc: nbd@nbd.name
Subject: Re: [RFC 3/6] mac80211: add a TXQ for other powersave-buffered frames
Date: Mon, 26 Jun 2017 16:27:06 +0200	[thread overview]
Message-ID: <1498487226.24675.3.camel@sipsolutions.net> (raw)
In-Reply-To: <b01d8009-80ba-e437-02b8-5a120c2927e4@candelatech.com>

On Mon, 2017-06-26 at 07:15 -0700, Ben Greear wrote:

> > This *can* be solved, even in this piece of code I inserted here,
> > but it'd have to keep state about the queues and then insert some
> > hooks elsewhere. I'm pretty sure I can solve that, but don't have
> > the time (or even hardware) to test this (easily, I have ath10k in
> > a few routers, but ...).
> 
> What/how is it relying on buffering?

So with the TXQs, I thought we were only buffering in mac80211 on the
TXQs themselves. This isn't true though!

We still have the local->pending queues, and the drivers will still
rely on this for all the frames that are *not* going through a TXQ,
which currently is:
 * all non-data frames
 * multicast data frames if they need to be sent after DTIM
   (not sure why this is - doesn't make much sense to me to
    differentiate immediate and after-DTIM transmissions)
 * data frames to stations the driver doesn't know about (yet)

In this case, the driver can still call ieee80211_stop_queue() or
similar, and expect frames to be buffered. I completely failed to take
that into account in this patchset; the dequeue logic I added to ath9k
and ath10k would have to take that into account and not dequeue if the
corresponding queue was stopped.

I think we'll probably have to put this logic into the current
driver(s); I was planning to put it into mac80211 for non-TXQ drivers,
but the ones already using TXQs would have to deal with it, since it'd
be really hard to make mac80211 logic kick in only partially for some
TXQs and not for others.

However, due to all the different levels of buffering we need more TXQs
than I introduced in this patchset (except I really don't want to
introduce one for per-vif-multicast-dtim-buffered-data ...)

> I'd be happy to send you plenty of ath10k mini-pcie NICs if that
> would help.

No need; I have no doubt that I could obtain them, but now I'll be
going on sabbatical for 2 months anyway :-)

johannes

  reply	other threads:[~2017-06-26 14:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21 23:50 [RFC 1/6] mac80211: agg-tx: call drv_wake_tx_queue in proper context Johannes Berg
2017-06-21 23:50 ` [RFC 2/6] mac80211: fix VLAN handling with TXQs Johannes Berg
2017-06-21 23:50 ` [RFC 3/6] mac80211: add a TXQ for other powersave-buffered frames Johannes Berg
2017-06-22  0:02   ` Ben Greear
2017-06-22  6:24     ` Johannes Berg
2017-06-22 14:43       ` Ben Greear
2017-06-23  9:21         ` Johannes Berg
2017-06-23 12:27           ` Ben Greear
2017-06-26 11:00             ` Johannes Berg
2017-06-26 14:15               ` Ben Greear
2017-06-26 14:27                 ` Johannes Berg [this message]
2017-06-21 23:50 ` [RFC 4/6] mac80211: don't put null-data frames on the normal TXQ Johannes Berg
2017-06-21 23:50 ` [RFC 5/6] mac80211: add a general fallback TXQ Johannes Berg
2017-06-22  8:48   ` Johannes Berg
2017-06-21 23:50 ` [RFC 6/6] mac80211: always go through txqs 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=1498487226.24675.3.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=greearb@candelatech.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@nbd.name \
    /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).