From: Felix Fietkau <nbd@nbd.name>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>,
"Tim Shepard" <shep@alum.mit.edu>
Cc: linux-wireless@vger.kernel.org,
make-wifi-fast@lists.bufferbloat.net,
ath9k-devel@lists.ath9k.org
Subject: Re: [Make-wifi-fast] [PATCH] ath9k: Switch to using mac80211 intermediate software queues.
Date: Wed, 06 Jul 2016 13:23:51 -0000 [thread overview]
Message-ID: <2c4c9821-fea6-fc95-f6a3-cf95e703cce6@nbd.name> (raw)
In-Reply-To: <87lh1hnvn6.fsf@toke.dk>
On 2016-07-04 19:46, Toke Høiland-Jørgensen wrote:
> Tim Shepard <shep@alum.mit.edu> writes:
>
>> Thanks for unconfusing me a couple weeks ago, and cluing me into how
>> the limit on ->pending_frames is not really relevant for the data
>> packets that go through the new intermediate queues.
>>
>> But I'm not sure if this would allow us to remove the limit on
>> pending_frames because even though normal data packets would not
>> normally build up that many packets, there are other packet types
>> which bypass the intermediate queues and are transmitted directly
>> (also in most cases bypassing the ath9k internal queues in the way
>> ath9k worked before we patched it to use the mac80211 intermediate
>> queues).
>
> Yes, but, well, since they're not queued they are not going to overflow
> anything. The aggregation building logic stops at two queued aggregates,
> so the default limit of 123 packets is never going to be hit when the
> queue is moved into the mac80211 layer. So keeping the knobs around only
> helps people who purposefully want to cripple their ability to do
> aggregation; and it won't be doing what it promises (limiting qlen),
> since that is now moved out of the driver. So IMO, removing the knobs is
> the right thing to do. I have already updated my patch to do so, which
> I'll send as a v2 once the other bits are resolved.
I agree.
>> Earlier Felix said:
>>
>>> Channel context based queue handling can be dealt with by
>>> stopping/starting relevant queues on channel context changes.
>>
>> But I don't see how to handle the case here where packets get passed
>> to the driver with ath_tx_start() and wind up in the scenario above.
>
> Well, presumably the upper layers won't try to transmit anything through
> the old TX path if the start/stop logic is implemented properly. The
> chanctx code already seems to call the ieee80211_{start,stop}_queue()
> functions when changing context, so not sure what else is needed. Guess
> I'll go see if I can provoke an actual triggering of the bug, unless
> Felix elaborates on what he means before I get around to it (poke,
> Felix? :)).
Then I guess the logic in ath_tx_start was a leftover from a time before
some queue related rework happened to the chanctx code.
In that case you can simply remove the chanctx related software queueing
stuff from ath_tx_start.
- Felix
next prev parent reply other threads:[~2016-07-06 13:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1bJYSp-0001M8-00@www.xplot.org>
2016-07-04 17:46 ` Toke Høiland-Jørgensen
2016-07-06 13:23 ` Felix Fietkau [this message]
2016-07-06 14:45 ` Toke Høiland-Jørgensen
[not found] <E1bEcwS-0006jR-00@www.xplot.org>
2016-06-19 13:50 ` Toke Høiland-Jørgensen
[not found] <E1bETEY-0000BM-00@www.xplot.org>
2016-06-19 8:52 ` Toke Høiland-Jørgensen
[not found] <20160617090929.31606-2-toke@toke.dk>
2016-06-18 19: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
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c4c9821-fea6-fc95-f6a3-cf95e703cce6@nbd.name \
--to=nbd@nbd.name \
--cc=ath9k-devel@lists.ath9k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=shep@alum.mit.edu \
--cc=toke@toke.dk \
/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