Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191004062151.131405-1-kyan@google.com> <20191004062151.131405-2-kyan@google.com>
 <87imp4o6qp.fsf@toke.dk> <CA+iem5vJFRxskyHOKf5K73X8aGH965P4hoiCj-wQtK-Z-47pdg@mail.gmail.com>
 <87pnj9n55y.fsf@toke.dk> <aa40e945adfbeb52890afb2de493142e82ecf69d.camel@sipsolutions.net>
 <878spwmjif.fsf@toke.dk> <600f64e1e673fff25d2be71ac767d7332db0452a.camel@sipsolutions.net>
In-Reply-To: <600f64e1e673fff25d2be71ac767d7332db0452a.camel@sipsolutions.net>
From:   Kan Yan <kyan@google.com>
Date:   Wed, 9 Oct 2019 19:35:06 -0700
Message-ID: <CA+iem5uemV7YB=DPry5UdgLgi0USXG-e3My2=3256EWtFkye4Q@mail.gmail.com>
Subject: Re: [PATCH 1/2] mac80211: Implement Airtime-based Queue Limit (AQL)
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@redhat.com>,
        linux-wireless@vger.kernel.org,
        make-wifi-fast@lists.bufferbloat.net, Felix Fietkau <nbd@nbd.name>,
        Yibo Zhao <yiboz@codeaurora.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

> I'd like to use the new rate calculation code that Felix added to mt76.
> Is the arsta->txrate info in ath10k suitable to be passed up to mac80211
> and used in that, do you think? Because then that would probably be the
> easiest way to go about it...

Do you mean the mt76 patch that using the EWMA to smooth estimate data
rate? It would be great if you can move that to mac80211.
Yes, arsta->txrate info in ath10k is a good place to extract latest date ra=
te.


On Mon, Oct 7, 2019 at 12:43 PM Johannes Berg <johannes@sipsolutions.net> w=
rote:
>
> On Mon, 2019-10-07 at 21:40 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote=
:
>
> > > > So if and when we start supporting true multi-band devices we'll ha=
ve to
> > > > change these things anyway. So might as well keep everything togeth=
er so
> > > > it all gets fixed :)
> > >
> > > I guess I'm OK with that, but I'm pretty sure this will come up soone=
r
> > > rather than later ...
> > >
> > > What else is there though?
> >
> > By "it all" I meant "all the airtime fairness stuff". Other than that, =
I
> > didn't have anything in particular in mind. I just kinda assumed there
> > would be lots of places that had an implicit assumption that all device=
s
> > on the same phy shares a channel...
>
> Not _that_ much - we do have the channel contexts after all. But except
> for hwsim (*cough cough* I was lazy) nothing actually implements real
> concurrent multi-channel yet, obviously, but uses a single radio with
> channel hopping...
>
> johannes
>