On Wed, 2022-10-05 at 14:26 +0200, Toke Høiland-Jørgensen wrote:
> > void ieee80211_handle_wake_tx_queue(struct ieee80211_hw *hw,
> > struct ieee80211_txq *txq)
> > {
> > ... *local = from_hw(hw);
> > ... *sdata = from_vif(txq->vif);
> >
> > wake_tx_push_queue(local, sdata, txq);
> > }
> >
> > Actually ... I wonder why you'd here - in waking a single TXQ - use
> > ieee80211_next_txq() at all, Toke, what do you think?
>
> Well, this patch does almost exactly the same as the ath9k driver does,
> for instance. Really, the wake_tx_queue() is a signal to the driver to
> start transmitting on the *hardware* queue that the txq points to. For
> some drivers (like Intel, right?) that's a 1-to-1 mapping, for others
> there are multiple TXQs being scheduled on the same HW-TXQ. So I think
> it's probably the right thing to do to just call next_txq(); if there's
> only a single TXQ scheduled it should be pretty cheap to do so.
Oh OK. So then the logic Alexander had makes sense.
>
> This logic has implications for putting "urgent" frames (like PS(?)) on
> TXQs as well, of course, but that needs to be handled somehow anyway...
But that probably then anyway needs to be handled in next_txq()?
johannes
