Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes:
> 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.
Yup, I think so :)
>>
>> 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()?
Yeah, just meant that comment as an "for future reference", it doesn't
impact this patch series (I think?)
-Toke
