<p dir="ltr">> > What wifi needs is a bit different:<br>
> ><br>
> > (hosts/aggregates?) -> (shapers/minstrel?) -> priority -> flows -> signalling -> queues</p>
<p dir="ltr">> Yep.</p>
<p dir="ltr">> I don't see a huge need for "shaping" on wifi. I do see a huge need - as a starting point - an airtime fair per station queue that is aggregation aware, and slightly higher up, something that is aware of the overall workload on the AP.</p>
<p dir="ltr">Which is basically what I'm thinking of. "Airtime fair" is also known as "proportional fair". You need to know the data rate to each station for that.</p>
<p dir="ltr">But knowing the data rate via minstrel, and the average expected time between transit opportunities to each station (which could probably be calculated rather than measured), would allow inferring certain things that I currently do using the shaper in cake, such as the appropriate size for the aggregate, and the amount of bandwidth that we can allow priority in. The only reason I can't reliably do that in cake with the shaper disabled is because I can't sense the hardware link rate, which is exactly what minstrel is in charge of.</p>
<p dir="ltr">Incidentally, I suspect that aggregates of equal temporal length are valuable for multi station MIMO.</p>
<p dir="ltr">It's also pretty obvious that selective link layer acks need to be acted on, and aggregates reformed for each transmit opportunity, whether a retry or not. I'm very disappointed to hear that those things often aren't already done, but it's probably a consequence of leaving that functionality to the hardware vendors so far. It's even possible that the current mess of binary blobs is a consequence of the weak support for aggregation in the kernel.</p>
<p dir="ltr">Probably not so much raw code (which autocorrected to coffee TWICE) can be reused from cake, not least due to simply operating at a different layer of the stack, but I think a lot of the conceptual advances can.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>