netdev - Re: taprio vs. wireless/mac80211

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 26 Aug 2022 17:13:44 -0700
From:   Dave Taht <dave.taht@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Johannes Berg <johannes@...solutions.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Toke Høiland-Jørgensen <toke@...e.dk>,
        Avi Stern <avraham.stern@...el.com>,
        linux-wireless <linux-wireless@...r.kernel.org>
Subject: Re: taprio vs. wireless/mac80211

On Fri, Aug 26, 2022 at 5:05 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Fri, 26 Aug 2022 15:10:36 -0700 Vinicius Costa Gomes wrote:
> > Jakub Kicinski <kuba@...nel.org> 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