Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes:
> On Mon, 2018-09-10 at 15:08 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes:
>>
>> > On Mon, 2018-09-10 at 14:39 +0200, Toke Høiland-Jørgensen wrote:
>> >
>> > > > From then on, right now we basically just try to refill the hardware
>> > > > queue from the TXQ whenever the hardware releases frames from that
>> > > > queue. If there are none, we fall back to putting them on the hardware
>> > > > queue from the wake signal.
>> > >
>> > > OK. So if the TXQ is ineligible to dequeue packets, but still have them
>> > > queued, there would need to be a signal (such as wake_txq()) when it
>> > > becomes eligible again, right?
>> >
>> > Right. It wouldn't have to be wake_txq, but that seems as appropriate as
>> > anything else.
>> >
>> > If we were to use ieee80211_airtime_may_transmit(), we'd have to have
>> > something that tells us "I previously told you it may not transmit, but
>> > now I changed my mind" :-)
>>
>> Yes, exactly. Hmm, I'll see what I can come up with :)
>
> No need to look at this right now - let's get this stuff sorted out
> first :)
Right, sure, I'll get the port of ath9k done first; but doesn't hurt to
think about API compatibility with the other drivers at the same time as
well...
If we have the start_schedule() / end_schedule() pair anyway, the latter
could notify any TXQs that became eligible during the scheduling round.
Also, instead of having the three different API functions
(next_txq()/may_tx()/schedule_txq()), we could have get_txq(txq)/put_txq(txq)
which would always need to be paired; but the argument to get_txq()
could be optional, and if the driver passes NULL it means "give me the
next available TXQ".
So for ath9k it would be:
start_schedule(ac);
while ((txq = get_txq(NULL)) {
queue_aggregate(txq);
put_txq(txq);
}
end_schedule(ac);
And for ath10k/iwlwifi it would be:
on_hw_notify(txq) {
start_schedule(ac);
if (txq = get_txq(txq)) {
queue_packets(txq);
put_txq(txq);
}
end_schedule(ac);
}
I think that would be simpler, API-wise?
-Toke
