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: <2d932e4d-6f4b-c6f6-3e14-d7d98d4f5b71@engleder-embedded.com>
Date:   Mon, 23 Jan 2023 23:20:28 +0100
From:   Gerhard Engleder <gerhard@...leder-embedded.com>
To:     Vladimir Oltean <vladimir.oltean@....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 23.01.23 22:31, Vladimir Oltean wrote:
> 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?

Yes, with the current design only 1 TXQ per traffic class is the goal.

>>> 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?

There can be less TCs than TXQs. If only the second TXQ would be used,
then gate mask per TC would be 0x1 and gate mask per TXQ would be 0x2.

If number of TCs and TXQs would be identical, then there would be no
difference. The overlap check enforces that TXQs are assigned to TCs in
strict order. So TXQs cannot be assigned to TCs in arbitrary order. At
least that was the result of a quick test. But I don't know what's the
reason of this behavior.

Gerhard