Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Mon, 2018-09-10 at 12:57 +0200, Toke Høiland-Jørgensen wrote: >> Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: >> >> > On Sat, 2018-09-08 at 00:22 +0200, Toke Høiland-Jørgensen wrote: >> > > >> > > Usage of the new API is optional, so drivers can be ported one at a time. >> > >> > With the 1:1 hardware queue/txq mapping in iwlwifi (we're close to >> > getting that patch in, though now the Jewish holidays mean a delay), >> > I'm not sure we'd be able to do this at all in iwlwifi. So this may >> > not be a case of porting one at a time until we can get rid of it ... >> >> Could you elaborate a bit more on how the hwq/txq stuff works in iwl? > > I can try. > >> Does the driver just hand off a TXQ to the hardware on wake_txq(), which >> is then scheduled by the hardware after that? Or how does the mapping to >> hwqs work, and how is the hardware notified that there are still packets >> queued / that new packets have arrived for an already mapped txq? > > Basically, we use the TXQ driver data to do this. On initialization, we > set all TXQs to have no hardware queue mapped. Then, when the first wake > happens for this TXQ, we allocate a hardware queue for this RA/TID. > > 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? -Toke
