> On 6 Apr, 2016, at 10:16, Michal Kazior <michal.kazior@xxxxxxxxx> wrote: > > When a driver asks mac80211 to dequeue given txq it implies a > destination station as well. This is important because 802.11 > aggregation can be performed only on groups of packets going to a > single station on a single tid. > > Cake - as I understand it - doesn't really *guarantee* maintaining > this. Keep in mind you can run with hundreds of stations connected. > > You don't really want to burden drivers with sorting this grouping up > themselves (and hence coerce them into introducing another level of > intermediate queues, bis). Well, no. Cake isn’t designed to maintain per-station queues explicitly, though it does have support for stochastic fairness between hosts. It is also blissfuly unaware of the requirements of wifi aggregation, largely because the standard qdisc interface is likewise ignorant. I’m therefore not suggesting that you use Cake as-is. What I’m pointing at instead is the set-associative hash, which could easily be tweaked to put greater emphasis on avoiding putting multiple stations’ traffic in one queue, while maintaining the performance benefits of a fixed queue pool indexed by a hash table, and an extended operating region in which flow isolation is maintained. You can then have a linked-list of queues assigned to a particular station, so that when a packet for a particular station is requested, you can easily locate one. I hadn’t appreciated, though, that the TXQ struct was station-specific. This wasn’t obvious from the code fragments posted, so it looked like packets that incurred hash collisions would be dumped into a single overflow queue. - Jonathan Morton -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
