On Wed, 2017-10-11 at 16:29 +0200, Toke Høiland-Jørgensen wrote: > 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? Yes, but they need to be somehow taken off the queue to avoid reordering. Usually the firmware will filter them, but synchronisation is difficult, since what might happen is that some frames are already filtered, others aren't, and then the later ones actually need to go out while the earlier ones don't ... if that's not done, you get reordering and the state machines get out of sync. > 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? Hmm. I don't think the standard will actually help you much here, it just describes the over-the-air behaviour. Most of the complexity here comes from having to deal with driver buffering, mac80211 buffering, addressing the reordering problem (described above) from queuing frames for multiple stations on the same hw queue. johannes
