Johannes Berg <johannes@xxxxxxxxxxxxxxxx> writes: > On Wed, 2017-10-11 at 16:06 +0200, Toke Høiland-Jørgensen wrote: > >> > Hmm, not sure. We really want this to be scheduled pretty much >> > immediately because the other side will be waiting for the frames, >> > and >> > if we don't get an answer out quickly it'll have to assume we're >> > broken. I don't know what the limit here is for our firmware, but >> > we >> > should really get this out as soon as possible in this case. >> >> OK. But presumably it can't preempt packets already pushed to the >> hardware, right? > > True. If there are still packets scheduled then it needs even more > driver tricks to drop those back to tx_pending first ... Only for packets to the same station, right? >> So telling the driver to immediately schedule a packet, >> and making sure that the txq it gets from next_txq() is the right one >> should do the trick? But I guess it's a bit of a roundabout way, >> which may not be worth it to avoid an extra callback... > > Yeah, might work, but remember that we need to mangle the packet, and > for that we need to know how many packets will go out. E.g. with U- > APSD, if we tell the driver 8 packets are OK, and it only wants 6, then > that's acceptable, but we have to tag the last of those with EOSP ... > > So one way or another I think we need a separate callback here, and > perhaps just have the driver do the EOSP tagging, or have a separate > function to pull the frames so mac80211 can do the tagging, dunno. Yeah, sounds like it'll need a separate callback, or at least a flag. What part of the standard do I have to read to learn how this is supposed to work, BTW? Or even better, is there a resource that describes how PS works that is more accessible than the standard itself? > Note that this is only for _some_ drivers, others will implement much > of this in firmware. Right, of course. Fun times! :) -Toke
