Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Joshua Zhao <swzhao@gmail.com>
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] tx queue stuck for many minutes
Date: Fri, 12 Apr 2019 21:57:10 +0200	[thread overview]
Message-ID: <87ftqnvvxl.fsf@toke.dk> (raw)
In-Reply-To: <CAKmTU=rS2p0hB+5h8mY9aC3_Bhqi88_JXxGVqjeyK3SXEMfFuw@mail.gmail.com>

Joshua Zhao <swzhao@gmail.com> writes:

> Hi,
> Thanks for the reply!  I've also emailed the ath10k and linux-wireless list
> and waiting to hear back suggestions.
> In the meantime can you educate me how the aqm queue interacts with wifi
> driver? Is that the driver pulls from the queue from time to time, instead
> of aqm pushes to the network interface? How often or what triggers the
> driver to pull?

Generally two paths:

1. Packet comes in from upper netdev -> mac80211 queues the packet to tx ->
   driver is notified through wake_tx_queue() op, driver initiates
   transmission scheduling and pulls from TXQ

and

2. Driver gets notification from hardware (mostly TX completion) ->
   driver initiates TX scheduling and pulls from TXQ

There are some more cases that are variants of the above (e.g., wakeup
from powersave etc). My guess is that in your case it is one of the
cases in the second category that goes wrong...

> I hope I can verify that if you can point me to the code to check that
> :) And, for the queue itself, how long it's supposed to drop packets
> and clean up?

Well, when the hardware is reset, or the station is disassociated, the
queue will be flushed. Other than that, there's no separate "cleanup"
per se; rather, the two mechanisms outlined above should ensure that
packets keep flowing towards the station at the other end.

> It seems that when it's full, it notifies back-pressure to the socket
> instead of simply dropping the packets from the head or the tail of
> the queue?

No, it doesn't generally do much back-pressure. Rather, when it fills
up, it will drop packets from the head of the longest flow to clear
space (see fq_tin_enqueue()). The limit is pretty high, though - 8192
packets or 16 Mbytes of memory...

-Toke

  reply	other threads:[~2019-04-12 19:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 23:38 Joshua Zhao
2019-04-12  0:04 ` Joshua Zhao
2019-04-12  9:18 ` Toke Høiland-Jørgensen
2019-04-12 17:26   ` Joshua Zhao
2019-04-12 19:57     ` Toke Høiland-Jørgensen [this message]
2019-04-12 23:03       ` Joshua Zhao
2019-04-13  6:45         ` 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=87ftqnvvxl.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=swzhao@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox