[Make-wifi-fast] [Cake] Cake in mac80211

[Toke Høiland-Jørgensen]

Dave Taht <dave at taht.net> writes:

> Bjørn Ivar Teigen <bjorn at domos.no> writes:
>
>> Thanks for the feedback!
>>
>> Some comments and questions added inline.
>>
>> On Tue, 4 Feb 2020 at 18:07, Dave Taht <dave.taht at gmail.com> wrote:
>>
>>     On Tue, Feb 4, 2020 at 7:25 AM Jonathan Morton
>>     <chromatix99 at gmail.com> wrote:
>>     >
>>     > > On 4 Feb, 2020, at 5:20 pm, Bjørn Ivar Teigen <bjorn at domos.no>
>>     wrote:
>>     > >
>>     > > Are there any plans, work or just comments on the idea of
>>     implementing cake in mac80211 as was done with fq_codel?
>>     >
>>     > To consider doing that, there'd have to be a concrete benefit to
>>     doing so.
>>     
>>     Research is research! :) Everything is worth trying! There's got
>>     to be
>>     some better ideas out there, and we have a long list of things we
>>     could have done to keep improving wifi had funding not run out.
>>     
>>     We barely scratched the surface of this list.
>>     
>>     https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit
>>    
>>     
>>     > Most of Cake's most useful features, beyond what fq_codel
>>     already supports, are actually implied or even done better by the
>>     WiFi environment and the mac80211 layer adaptation (particularly
>>     airtime fairness).
>>     
>>     In my opinion(s)
>>     
>>     A) I think ack-filtering will help somewhat on 802.11n, but it's
>>     not
>>     worth the added cpu cost on an AP and I'd prefer hosts reduce
>>     their
>>     ack load in the tcp stack (IMHO, others may differ, it's worth
>>     trying)
>>     B) The underlying wifi scheduler essentially does per host fq
>>     better
>>     than cake can (because it's layer 2 vs layer 3), as per jonathan's
>>     comment above 
>>
>>     C) Instead of using a 8 way set associative hash and 1024 queues,
>>     fq_codel for wifi uses 4096 with a disambiguation pointer for
>>     collisions. Seems good enough.
>>     
>>
>> Didn't catch that before. Are the extra queues there because of the
>> different access categories on Wi-Fi? Seems like that would mean most
>> of them are not in use considering how little traffic is marked with
>> DSCP.
>
> I wasn't counting those. There's one set of 4k queues per access
> class.

Nit: not per access class; they're shared across the whole phy.

-Toke