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;
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org,
        make-wifi-fast@lists.bufferbloat.net, ath10k@lists.infradead.org,
        John Crispin <john@phrozen.org>,
        Lorenzo Bianconi <lorenzo@kernel.org>,
        Felix Fietkau <nbd@nbd.name>, Kan Yan <kyan@google.com>,
        Rajkumar Manoharan <rmanohar@codeaurora.org>,
        Kevin Hayes <kevinhayes@google.com>
Subject: Re: [PATCH v6 2/4] mac80211: Import airtime calculation code from mt76
In-Reply-To: <42266e95f45d5772e04c9c016bd6179ea14ffefa.camel@sipsolutions.net>
References: <157182473951.150713.7978051149956899705.stgit@toke.dk> <157182474174.150713.17459330922820192258.stgit@toke.dk> <42266e95f45d5772e04c9c016bd6179ea14ffefa.camel@sipsolutions.net>
Date:   Fri, 08 Nov 2019 11:55:35 +0100
Message-ID: <87d0e2fxi0.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Johannes Berg <johannes@sipsolutions.net> writes:

> On Wed, 2019-10-23 at 11:59 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote=
:
>> From: Toke H=C3=B8iland-J=C3=B8rgensen <toke@redhat.com>
>>=20
>> Felix recently added code to calculate airtime of packets to the mt76
>> driver. Import this into mac80211 so we can use it for airtime queue lim=
it
>> calculations later.
>>=20
>> The airtime.c file is copied verbatim from the mt76 driver, and adjusted=
 to
>> use mac80211 data structures instead (which is fairly straight forward).
>> The per-rate TX rate calculation is split out to its own
>> function (ieee80211_calc_tx_airtime_rate()) so it can be used directly f=
or
>> the AQL calculations added in a subsequent patch.
>
> Any way it could be exposed by mac80211 back to the drivers, perhaps, to
> share it?

Didn't I already export some of the functions? My intention was to do
that, certainly, and to patch mt76 to switch to using them once the
trees have converged...

>> The only thing that it was not possible to port directly was the bit tha=
t
>> read the internal driver flags of struct ieee80211_rate to determine
>> whether a rate is using CCK or OFDM encoding. Instead, just look at the
>> rate index, since at least mt76 and ath10k both seem to have the same
>> number of CCK rates (4) in their tables.
>
> This is highly questionable ...
>
>> +=09switch (status->encoding) {
>> +=09case RX_ENC_LEGACY:
>> +=09=09if (WARN_ON_ONCE(status->band > NL80211_BAND_5GHZ))
>> +=09=09=09return 0;
>> +
>> +=09=09sband =3D hw->wiphy->bands[status->band];
>> +=09=09if (!sband || status->rate_idx > sband->n_bitrates)
>> +=09=09=09return 0;
>> +
>> +=09=09rate =3D &sband->bitrates[status->rate_idx];
>> +=09=09cck =3D (status->rate_idx < CCK_NUM_RATES);

Heh, yeah this did feel like a hack to me as well ;)

> Why not
>
> =09cck =3D rate->flags & IEEE80211_RATE_MANDATORY_B;
>
> I mean .. we know that IEEE80211_RATE_MANDATORY_B rates are exactly the
> CCK rates, and that's not really going to change?
>
> Alternatively, we could do
>
> =09cck =3D sband->band =3D=3D NL80211_BAND_2GHZ &&
> =09      !(rate->flags & IEEE80211_RATE_ERP_G);
>
> or even
>
> =09cck =3D rate->bitrate =3D=3D 10 || rate->bitrate =3D=3D 20 ||
> =09      rate->bitrate =3D=3D 55 || rate->bitrate =3D=3D 110;

I am fine with either of those; I just wasn't sure what assumptions I
could actually make here. I guess I'll just pick one :)

>> +=09default:
>> +=09=09WARN_ON_ONCE(1);
>
> You can't do that in mac80211 either. That might be fine for mt76, but
> mac80211 already supports HE.

Good point, will fix.

-Toke