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

Message-ID: <20230123213144.jixdztjnut4tnf6r@skbuf>
Date:   Mon, 23 Jan 2023 23:31:44 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Gerhard Engleder <gerhard@...leder-embedded.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>,
        Vinicius Costa Gomes <vinicius.gomes@...el.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 Mon, Jan 23, 2023 at 10:21:33PM +0100, Gerhard Engleder wrote:
> For my tsnep IP core it is similar, but with reverse priority. TXQ 0 has
> the lowest priority (to be used for none real-time traffic). TXQ 1 has
> priority over TXQ 0, TXQ 2 has priority over TXQ 1, ... . The number of
> TX queues is flexible and depends on the requirements of the real-time
> application and the available resources within the FPGA. The priority is
> hard coded to save FPGA resources.

But if there's no round robin between queues of equal priority, it means
you can never have more than 1 TXQ per traffic class with this design,
or i.o.w., your best-effort traffic will always be single queue, right?

> > Furthermore (and this is really the biggest point of contention), myself
> > and Vinicius have the fundamental disagreement whether the 802.1Qbv
> > (taprio) gate mask should be passed to the device driver per TXQ or per
> > TC. This is what patch 11/11 is about.
> 
> tsnep also expects gate mask per TXQ. This simplifies the hardware
> implementation. But it would be no problem if the gate mask would be
> passed per TC and the driver is able to transform it to per TXQ.

If tsnep can only have at most 1 TXQ per TC, then what's the difference
between gate mask per TXQ and gate mask per TC?