From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 6098D3CB35 for ; Wed, 23 Oct 2019 11:38:50 -0400 (EDT) Received: by mail-lf1-x133.google.com with SMTP id x4so10171640lfn.8 for ; Wed, 23 Oct 2019 08:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wsRPOeJjtBdS2Tuyc/4JcmeBsaXWHy9aH1suUNQdJMo=; b=SeZ6GLemztlbLFMn0l6DCiiTEFLLO6k5/RPMRB9VrGHoW7yLj9h/TcSCg5Krv4gvgy TYFfwj7swgcC+kdfpmWS7yr6U2dmSm38+wMQB6S3SL2ylGybbpgIhdG1qvoW8oDJ6PSq MaAyPhYSfQIXXibPujGppMJq3b3ssxQldw8YljZGmdh3QkIihGKPbuwcAFOFlGy6eoom n9/zCPgJRUNmfLKx4gIxaiWp+7Np0S3YyI2NYxKWg4NjicIjEXdsLz6GlncMXeumj7Y1 n5I933B0gYWQYsULmVssG/Xf5IOcGDHoVpSK3ee/5tUbXVcg9CmpRjX2CXGGx6SNton7 vTjQ== 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=wsRPOeJjtBdS2Tuyc/4JcmeBsaXWHy9aH1suUNQdJMo=; b=qQxkhXwQ8kEPIqyVIwubJtU74853byq/mfiuQT405xioSJ5/xN952IV+pIRS5YeNqu rPPH7MT22y1kB3is6s0LRsor9oRVPk4YH8lHZPSQb9cisE6370i+DxUDeZhgN2/SSudJ inF6oovX2VweEJqgKy3nV/+KaBk4dACLd+QJN6U8Ml+Itr7zoQopzyujq22QQgCYbmoz 5LdEjRni2z+VDJV0fXfFd56BMLT8VL1f+XJGfebwUZKCzhFYhVVNqeodX73bjxSq+wFi 6F3byN7kNLs9V7yNGTRFgia/KqbBWXXas93iR6arjZhjicPRJtFIYucf8XxYzECWl5Go 8H4Q== X-Gm-Message-State: APjAAAVWK2VJzpUMjPi2IV/UMz20xbG9IXZfJoPT3HubrL2dP2tfeMa6 oDX1OCnqGmXlhv48x3dDkHma5UK0kHEx6zTU1jzohA== X-Google-Smtp-Source: APXvYqzPxK254RWPC33bZq436iRvQMPI5AidKpxpfauS+kkgeIOZc6e3qcTjqZrkFWrQN+bR4SertoWNKkpLyCo5LaQ= X-Received: by 2002:a19:cc47:: with SMTP id c68mr9959830lfg.95.1571845128902; Wed, 23 Oct 2019 08:38:48 -0700 (PDT) MIME-Version: 1.0 References: <157148503415.2989444.7391437309981941226.stgit@toke.dk> <157148503865.2989444.7118792679603045723.stgit@toke.dk> <871rv5ovwr.fsf@toke.dk> <87tv7znact.fsf@toke.dk> <87lftbn60t.fsf@toke.dk> In-Reply-To: <87lftbn60t.fsf@toke.dk> From: Kan Yan Date: Wed, 23 Oct 2019 08:38:37 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Johannes Berg , linux-wireless@vger.kernel.org, Make-Wifi-fast , ath10k@lists.infradead.org, John Crispin , Lorenzo Bianconi , Felix Fietkau , Rajkumar Manoharan , Kevin Hayes Content-Type: multipart/alternative; boundary="0000000000008d4448059595b6c3" Subject: Re: [Make-wifi-fast] [PATCH v4 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue 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: Wed, 23 Oct 2019 15:38:50 -0000 --0000000000008d4448059595b6c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Aha! Turns out I was doing the sta lookup completely wrong in > ieee80211_report_used_skb(); so anything frames that were dropped and > went through there would not get its airtime subtracted correctly. Will > send a v6 with a fix :) Awesome, thanks! That looks very promising. The symptom I see with previous patch is the interface's pending airtime count looks fine, but the station's airtime get wrong, either due to airtime is credited to the wrong station or wrong AC. On Wed, Oct 23, 2019 at 2:52 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Toke H=C3=B8iland-J=C3=B8rgensen writes: > > > Kan Yan writes: > > > >>> >> + if (ieee80211_is_data_qos(hdr->frame_control)) { > >>> >> + qc =3D ieee80211_get_qos_ctl(hdr); > >>> >> + tid =3D qc[0] & 0xf; > >>> >> + ac =3D ieee80211_ac_from_tid(tid); > >>> >> + } else { > >>> >> + ac =3D IEEE80211_AC_BE; > >>> >> + } > >>> > > >>> > The tid/ac is incorrect either here or in __ieee80211_tx_status() > when > >>> > tested with ath10k. The ac is set to AC_BE with test done using BK > >>> > class traffic, hence the pending airtime get updated for the wrong > >>> > txq. > >>> > >>> Huh, well that won't do, obviously :) > >>> > >>> Any idea why it might be wrong? > >> > >> somehow ieee80211_is_data_qos() returns false. Besides, qos_control > >> field doesn't seems to be set in ieee80211_build_hdr(). > >> > >>> Hmm, I guess we could just get the ac using skb_get_queue_mapping(). > >>> I'll send an update with this fixed for you to try :) > >> Thanks for the quick update. It is getting much better, but > >> unfortunately the pending airtime accounting sometimes is still not > >> correct and cause txq stuck occasionally. > > > > OK, so that has to mean that there are packets getting dropped somewher= e > > without going through ieee80211_report_used_skb(). Assuming you're not > > hitting the underflow warnings, just seeing the counter not get back > > down to zero? > > > > Could you see if you can find out if ath10k does that anywhere? I'll go > > hunting in mac80211. > > > > Looking for calls to kfree_skb() or kfree_skb_list() should hopefully > > turn up something... > > Aha! Turns out I was doing the sta lookup completely wrong in > ieee80211_report_used_skb(); so anything frames that were dropped and > went through there would not get its airtime subtracted correctly. Will > send a v6 with a fix :) > > -Toke > > --0000000000008d4448059595b6c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aha! Tur= ns out I was doing the sta lookup completely wrong in
ieee80211_report_u= sed_skb(); so anything frames that were dropped and
went through there w= ould not get its airtime subtracted correctly. Will
send a v6 with a fix= :)
Awesome, thanks! That looks very promising.=C2=A0 The = symptom=C2=A0I see with previous=C2=A0patch is the interface's pending = airtime count looks fine, but the station's airtime get wrong, either d= ue to airtime is credited to the wrong station or wrong AC.

=
On Wed= , Oct 23, 2019 at 2:52 AM Toke H=C3=B8iland-J=C3=B8rgensen <toke@redhat.com> wrote:
Toke H=C3=B8iland-J=C3=B8rgensen <= toke@redhat.com>= ; writes:

> Kan Yan <kyan@= google.com> writes:
>
>>> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0if (ieee80211_is_data_qos(hdr->frame_control)) {
>>> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0qc =3D ieee80211_get_qos_ctl(hdr);
>>> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tid =3D qc[0] & 0xf;
>>> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ac =3D ieee80211_ac_from_tid(tid);
>>> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0} else {
>>> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ac =3D IEEE80211_AC_BE;
>>> >> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0}
>>> >
>>> > The tid/ac is incorrect either here or in __ieee80211_tx_= status() when
>>> > tested with ath10k. The ac is set to AC_BE with test done= using BK
>>> > class traffic, hence the pending airtime get updated for = the wrong
>>> > txq.
>>>
>>> Huh, well that won't do, obviously :)
>>>
>>> Any idea why it might be wrong?
>>
>> somehow=C2=A0 ieee80211_is_data_qos() returns false. Besides,=C2= =A0 qos_control
>> field doesn't seems to be set in ieee80211_build_hdr().
>>
>>> Hmm, I guess we could just get the ac using skb_get_queue_mapp= ing().
>>> I'll send an update with this fixed for you to try :)
>> Thanks for the quick update. It is getting much better, but
>> unfortunately the pending airtime accounting sometimes is still no= t
>> correct and cause txq stuck occasionally.
>
> OK, so that has to mean that there are packets getting dropped somewhe= re
> without going through ieee80211_report_used_skb(). Assuming you're= not
> hitting the underflow warnings, just seeing the counter not get back > down to zero?
>
> Could you see if you can find out if ath10k does that anywhere? I'= ll go
> hunting in mac80211.
>
> Looking for calls to kfree_skb() or kfree_skb_list() should hopefully<= br> > turn up something...

Aha! Turns out I was doing the sta lookup completely wrong in
ieee80211_report_used_skb(); so anything frames that were dropped and
went through there would not get its airtime subtracted correctly. Will
send a v6 with a fix :)

-Toke

--0000000000008d4448059595b6c3--