DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4FE0520859
MIME-Version: 1.0
References: <153908805217.9471.9290979918041653328.stgit@alrua-kau>
 <153908837900.9471.5394468800857658136.stgit@alrua-kau> <a65909ee425585a49d9e17f6504cf0ba@codeaurora.org>
 <87zhvm832s.fsf@toke.dk> <187bade306627912c70d800819ef0b87@codeaurora.org>
 <87pnwg93at.fsf@toke.dk> <7dfcb7a13a3f75f01f7b88163f2c33d6@codeaurora.org>
In-Reply-To: <7dfcb7a13a3f75f01f7b88163f2c33d6@codeaurora.org>
From:   Dave Taht <dave.taht@gmail.com>
Date:   Sat, 13 Oct 2018 00:09:58 -0700
Message-ID: <CAA93jw4ufN0i+-RpsLqHyfOjWyf3KuqY-yt8oi-OM5AT8fXF4Q@mail.gmail.com>
Subject: Re: [Make-wifi-fast] [PATCH RFC v5 3/4] mac80211: Add airtime
 accounting and scheduling to TXQs
To:     Rajkumar Manoharan <rmanohar@codeaurora.org>
Cc:     =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>,
        Kan Yan <kyan@google.com>,
        Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
        linux-wireless-owner@vger.kernel.org,
        linux-wireless <linux-wireless@vger.kernel.org>,
        Felix Fietkau <nbd@nbd.name>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Fri, Oct 12, 2018 at 12:38 AM Rajkumar Manoharan
<rmanohar@codeaurora.org> wrote:
>
> On 2018-10-11 03:38, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
> > Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
> >
> >> Hmm... mine is bit different. txqs are refilled only once for all
> >> txqs.
> >> It will give more opportunity for non-served txqs. drv_wake_tx_queue
> >> won't be
> >> called from may_tx as the driver anyway will not push packets in
> >> pull-mode.
> >
> > So, as far as I can tell, this requires the hardware to "keep trying"?
> > I.e., if it just stops scheduling a TXQ after may_transmit() returns
> > false, there is no guarantee that that TXQ will ever get re-awoken
> > unless a new packet arrives for it?
> >
> That is true and even now ath10k operates the same way in pull mode. Not
> just packet arrival, even napi poll routine tries to pushes the packets.
> One more thing, fetch indication may pull ~4ms/8ms of packets from each
> tid.
> This makes deficit too low and so refilling txqs by just airtime_weight
> becomes
> cumbersome. In may_transmit, the deficit are incremented by 20 *
> airtime_weight.
> In future this will be also replaced by station specific quantum. we can
> revisit
> this once BQL in place. Performance issue is resolved by this approach.
> Do you foresee any issues?

I'll have some time in the coming weeks to be able to test this stuff.
I'm mostly interested
in algorithmic correctness more than the API changes...

Is there a version of these patches that is stable enough on ath9 or ath10k=
?

Do I foresee any issues? Jeeze, no, we *never* have any issues with wifi.

"fetch indication may pull ~4ms/8ms of packets from each tid"

made me really twitchy.
>
> #define IEEE80211_TXQ_MAY_TX_QUANTUM  20
> bool ieee80211_txq_may_transmit(struct ieee80211_hw *hw,
>                                  struct ieee80211_txq *txq)
> {
>          struct ieee80211_local *local =3D hw_to_local(hw);
>          struct txq_info *txqi =3D to_txq_info(txq);
>          struct sta_info *sta;
>          u8 ac =3D txq->ac;
>
>          lockdep_assert_held(&local->active_txq_lock[ac]);
>
>          if (!txqi->txq.sta)
>                  goto out;
>
>          sta =3D container_of(txqi->txq.sta, struct sta_info, sta);
>          if (sta->airtime[ac].deficit >=3D 0)
>                  goto out;
>
>          list_for_each_entry(txqi, &local->active_txqs[ac],
> schedule_order) {
>                  if (!txqi->txq.sta)
>                          continue;
>                  sta =3D container_of(txqi->txq.sta, struct sta_info, sta=
);
>                  sta->airtime[ac].deficit +=3D
>                          (IEEE80211_TXQ_MAY_TX_QUANTUM *
> sta->airtime_weight);
>          }
>
>          return false;
>
>   out:
>          list_del_init(&txqi->schedule_order);
>          return true;
> }
>
> -Rajkumar
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast


--=20

Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740