netdev - Re: [RFC PATCH net-next 00/11] ENETC mqprio/taprio cleanup

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] [day] [month] [year] [list]

Message-ID: <20230126203949.vd2mptdxmbbz55r2@skbuf>
Date:   Thu, 26 Jan 2023 22:39:49 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Vinicius Costa Gomes <vinicius.gomes@...el.com>
Cc:     netdev@...r.kernel.org, John Fastabend <john.fastabend@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Camelia Groza <camelia.groza@....com>,
        Xiaoliang Yang <xiaoliang.yang_1@....com>,
        Gerhard Engleder <gerhard@...leder-embedded.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Kurt Kanzenbach <kurt@...utronix.de>,
        Ferenc Fejes <ferenc.fejes@...csson.com>,
        Tony Nguyen <anthony.l.nguyen@...el.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [RFC PATCH net-next 00/11] ENETC mqprio/taprio cleanup

On Wed, Jan 25, 2023 at 02:47:28PM -0800, Vinicius Costa Gomes wrote:
> > The problem with gates per TXQ is that it doesn't answer the obvious
> > question of how does that work out when there is >1 TXQ per TC.
> > With the clarification that "gates per TXQ" requires that there is a
> > single TXQ per TC, this effectively becomes just a matter of changing
> > the indices of set bits in the gate mask (TC 3 may correspond to TXQ
> > offset 5), which is essentially what Gerhard seems to want to see with
> > tsnep. That is something I don't have a problem with.
> >
> > But I may want, as a sanity measure, to enforce that the mqprio queue
> > count for each TC is no more than 1 ;) Otherwise, we fall into that
> > problem I keep repeating: skb_tx_hash() arbitrarily hashes between 2
> > TXQs, both have an open gate in software (allowing traffic to pass),
> > but in hardware, one TXQ has an open gate and the other has a closed gate.
> > So half the traffic goes into the bitbucket, because software doesn't
> > know what hardware does/expects.
> >
> > So please ACK this issue and my proposal to break your "popular" mqprio
> > configuration.
> 
> I am afraid that I cannot give my ACK for that, that is, for some
> definition, a breaking change. A config that has been working for many
> years is going to stop working.
> 
> I know that is not ideal, perhaps we could use the capabilities "trick"
> to help minimize the breakage? i.e. add a capability whether or not the
> device supports/"make sense" having multiple TXQs handling a single TC?
> 
> Would it help?

Not having multiple TXQs handling a single TC (that is fine), but having
multiple TXQs of different priorities handling a single tc...

So how does it work with igc, what exactly are we keeping alive?