From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Felix Fietkau <nbd@nbd.name>, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 1/6] mt76: use mac80211 txq scheduling
Date: Mon, 18 Mar 2019 23:14:28 +0100 [thread overview]
Message-ID: <87sgvjsud7.fsf@toke.dk> (raw)
In-Reply-To: <111434f9-f04c-2fe2-c2b4-de757efc884c@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> On 2019-03-17 22:59, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>>> I've looked at ath9k (the only user at the moment), and it seems to call
>>> the function in that way already: at PS wake or tx status time if it has
>>> frames in its internal retry queue.
>>> While it does not match the current documented behavior for that
>>> function, it nicely fits ath9k's currently unfulfilled expectations ;)
>>
>> Heh, fair point :)
> I noticed another issue: after the migration to the mac80211 txq
> scheduling code, ath9k does not handle stations going to powersave
> properly anymore. mac80211 keeps returning txqs for stations that have
> gone to sleep and ath9k will send out frames for them.
Ah, right. Never did have a good grip on the powersave code...
> We could deal with this in the driver and simply not return queues for
> stations in PS mode, or mac80211 could actively cancel them once a
> station enters PS mode. What do you prefer?
I think the cleanest would be if mac80211 handled it and just
un-scheduled stations when they go to sleep.
BTW, I was just thinking the other day about why the retry queue is kept
around when a station goes to sleep? Isn't the station usually sleeping
pretty long (>100 ms), where it might make more sense to drop things
rather than try again once i comes back?
-Toke
next prev parent reply other threads:[~2019-03-18 22:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-16 20:42 [PATCH 1/6] mt76: use mac80211 txq scheduling Felix Fietkau
2019-03-16 20:42 ` [PATCH 2/6] mt76: reduce locking in mt76_dma_tx_cleanup Felix Fietkau
2019-03-16 20:42 ` [PATCH 3/6] mt76: store wcid tx rate info in one u32 reduce locking Felix Fietkau
2019-03-16 20:42 ` [PATCH 4/6] mt76: store software PN/IV in wcid Felix Fietkau
2019-03-18 10:21 ` Stanislaw Gruszka
2019-03-18 10:37 ` Felix Fietkau
2019-03-16 20:42 ` [PATCH 5/6] mt76: move tx tasklet to struct mt76_dev Felix Fietkau
2019-03-16 20:42 ` [PATCH 6/6] mt76: only schedule txqs from the tx tasklet Felix Fietkau
2019-03-16 22:28 ` [PATCH 1/6] mt76: use mac80211 txq scheduling Toke Høiland-Jørgensen
2019-03-17 10:44 ` Felix Fietkau
2019-03-17 11:32 ` Toke Høiland-Jørgensen
2019-03-17 12:32 ` Felix Fietkau
2019-03-17 21:59 ` Toke Høiland-Jørgensen
2019-03-18 20:08 ` Felix Fietkau
2019-03-18 22:14 ` Toke Høiland-Jørgensen [this message]
2019-03-18 22:37 ` Felix Fietkau
2019-03-18 23:05 ` Toke Høiland-Jørgensen
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=87sgvjsud7.fsf@toke.dk \
--to=toke@redhat.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).