On Fri, Aug 26, 2022 at 5:05 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Fri, 26 Aug 2022 15:10:36 -0700 Vinicius Costa Gomes wrote: > > Jakub Kicinski <kuba@xxxxxxxxxx> writes: > > > > > On Wed, 24 Aug 2022 23:50:18 +0200 Johannes Berg wrote: > > >> Anyone have recommendations what we should do? > > > > > > Likely lack of sleep or intelligence on my side but I could not grok > > > from the email what the stacking is, and what the goal is. > > > > > > Are you putting taprio inside mac80211, or leaving it at the netdev > > > layer but taking the fq/codel out? > > > > My read was that they want to do something with taprio with wireless > > devices and were hit by the current limitation that taprio only supports > > multiqueue interfaces. > > > > The fq/codel part is that, as far as I know, there's already a fq/codel > > implementation inside mac80211. > > > > The stacking seems to be that packets would be scheduled by taprio and > > then by the scheduler inside mac80211 (fq/codel based?). > > Doesn't adding another layer of non-time-aware queuing after taprio > completely defeat its purpose? Perhaps I'm revealing my lack of > understanding too much.. > A pre wifi-7 mac itself is incapable of doing time aware queuing. It has to listen before talk, and wait til the media is free. Even if wifi-7 bears out, it's still dicy. So even if you only had one taprio'd packet in the sysem and no other packets, submitting that packet only starts an election to gain the media. -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC
