From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8BF073CB36 for ; Fri, 12 Apr 2019 13:26:12 -0400 (EDT) Received: by mail-it1-x132.google.com with SMTP id f22so16882359ita.3 for ; Fri, 12 Apr 2019 10:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T+QorttSPAnq/92micn7bLSmHAxDjcXjUn8f9O9TSOU=; b=fT/5YzcpJCKkpmrfPq7kB3CA5jNMyMAX8j5YuwSux1ynv/JcvRiwqbgMoNiiXWjiUK 7hdvFWbFzrTugO04FYBW1Fq84HbxFUt7kGVVsjYQuEdk5yVTiJ6CaZ0jnf8ehS8Fe/dS zaJSsIpkEE9+FluirrONAjQHVlY2DZrNMkD+gtncVstcyEc/8GUFrCf28pTVgz2pWp16 bO+ZMlh2T09Jpac98AgSt2uW2tkJyQ6PJ+myykQoy6xGQJtO/ryttMpZxrt7PpdTRhny Fd1kv62d6JChc92lQijrEyXlgndPDNQ1iL0Gf9mJU6Axtl6NcCRKOjME7Uitr2aiUuJ8 oc6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T+QorttSPAnq/92micn7bLSmHAxDjcXjUn8f9O9TSOU=; b=tILjw3oxuAia70nVXtpTLqoWJXmN4XhgA4ObKxu1rlpIFVsJMeNOPkdjNHkJyXFAZE 0LqsggVvjlechOHk97mBhc/7bGeRypAxnXri6yCHdiWWLxOU6w2Vxs5jCV+OhJTpeATo LjUUCSWQD8XshbxaZr7k4aIdZy3OExdG2pBiBjd0mhylECaxaBcucUbN19vKHZWqP3XI 07NIFPFu413zj6+5yULXK/J8UbDAwQIuhv+ov62I/om2k8OHPE3iYbJdj6r/BtbAhjnv 3Zr4GGSEWymAP16el8EVQipyPi54s1FRk9ZmpNw/UskI/5KoqQTnKMpSrGayS+A1S/FQ SUlw== X-Gm-Message-State: APjAAAUSThgVRBhtpqfMo1rvH6AdiCmLl+xeL8z08RNhgDofMvrmiGZN mbL88ltDe9QvDrVZB/sG4L/jqfikDfPHHYBOqDs= X-Google-Smtp-Source: APXvYqxCUKSMeskDczVqv4u9JU61AUamKM9vNm+ZMhxikY7vmqmNu12joIN1ADS7vSNnEauW2m7bpXlM2ixj4Ra98GI= X-Received: by 2002:a24:5f8c:: with SMTP id r134mr14427908itb.110.1555089971938; Fri, 12 Apr 2019 10:26:11 -0700 (PDT) MIME-Version: 1.0 References: <878swfshsk.fsf@toke.dk> In-Reply-To: <878swfshsk.fsf@toke.dk> From: Joshua Zhao Date: Fri, 12 Apr 2019 10:26:00 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: make-wifi-fast@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000005f0cde058658995e" X-Mailman-Approved-At: Fri, 12 Apr 2019 15:45:47 -0400 Subject: Re: [Make-wifi-fast] tx queue stuck for many minutes X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 17:26:12 -0000 --0000000000005f0cde058658995e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? 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? 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? Many thanks! Joshua On Fri, Apr 12, 2019 at 2:18 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Joshua Zhao writes: > > > Hi, > > I run into a weird symptom that occasionally the aqm tx queue can get > stuck > > for quite long time (maybe around 30min). What happened is that we're > > sending a low bandwidth UDP traffic from the host to multiple peers ove= r > a > > WiFi radio simultaneously. We're running opensource mac80211 + ath10k > > driver. Very occasionally when there are temporary issues causing troub= le > > on the host sending to one of the peers, the queue to all peers can get > > stuck and stay stuck for quite long (even though the link trouble had > been > > gone or TX had been stopped). Only after quite a while, then the queue > > cleans up. > > This sorta sounds like a driver bug where the queue doesn't get > restarted after the issue is resolved? I'd suggest you email the ath10k > (ath10k@lists.infradead.org - maybe cc linux-wireless@vger.kernel.org > and this list) with a description of the issue that triggers this bug, > as well as system details (hardware model, firmware version and kernel > version). > > -Toke > --0000000000005f0cde058658995e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Thanks for the reply!=C2=A0 I've also emailed = the ath10k and linux-wireless list and waiting to hear back suggestions.=C2= =A0
In the=C2=A0meantime can you educate me how the aqm queue int= eracts 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?
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? It seems that when= it's full, it notifies back-pressure to the socket instead of simply d= ropping the packets from the head or the tail of the queue?

<= /div>
Many thanks!
Joshua

On Fri, Apr 12, 2019 at 2:18 A= M Toke H=C3=B8iland-J=C3=B8rgensen <t= oke@redhat.com> wrote:
Joshua Zhao <swzhao@gmail.com> writes:

> Hi,
> I run into a weird symptom that occasionally the aqm tx queue can get = stuck
> for quite long time (maybe around 30min).=C2=A0 What happened is that = we're
> sending a low bandwidth UDP traffic from the host to multiple peers ov= er a
> WiFi radio simultaneously. We're running opensource mac80211 + ath= 10k
> driver. Very occasionally when there are temporary issues causing trou= ble
> on the host sending to one of the peers, the queue to all peers can ge= t
> stuck and stay stuck for quite long (even though the link trouble had = been
> gone or TX had been stopped). Only after quite a while, then the queue=
> cleans up.

This sorta sounds like a driver bug where the queue doesn't get
restarted after the issue is resolved? I'd suggest you email the ath10k=
(ath10k@lis= ts.infradead.org - maybe cc linux-wireless@vger.kernel.org
and this list) with a description of the issue that triggers this bug,
as well as system details (hardware model, firmware version and kernel
version).

-Toke
--0000000000005f0cde058658995e--