netdev - Re: Basic PCP/DEI-based queue classification

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: <871qsmf6rk.fsf@nvidia.com>
Date:   Thu, 8 Sep 2022 13:18:17 +0200
From:   Petr Machata <petrm@...dia.com>
To:     <Daniel.Machon@...rochip.com>
CC:     <vladimir.oltean@....com>, <Allan.Nielsen@...rochip.com>,
        <kuba@...nel.org>, <petrm@...dia.com>, <netdev@...r.kernel.org>,
        <vinicius.gomes@...el.com>, <thomas.petazzoni@...tlin.com>,
        <maxime.chevallier@...tlin.com>, <roopa@...dia.com>
Subject: Re: Basic PCP/DEI-based queue classification


<Daniel.Machon@...rochip.com> writes:

>> On Wed, Sep 07, 2022 at 10:41:10AM +0000, Daniel.Machon@...rochip.com wrote:
>> > > Regarding the topic at hand, and the apparent lack of PCP-based
>> > > prioritization in the software data path. VLAN devices have an
>> > > ingress-qos-map and an egress-qos-map. How would prioritization done via
>> > > dcbnl interact with those (who would take precedence)?
>> >
>> > Hi Vladimir,
>> >
>> > They shouldn't interact (at least this is my understanding).
>> >
>> > The ingress and egress maps are for vlan interfaces, and dcb operates
>> > on physical interfaces (dcbx too). You cannot use dcbnl to do
>> > prioritization for vlan interfaces.
>> >
>> > Anyway, I think much of the stuff in DCB is for hw offload only, incl. the
>> > topic at hand. Is the APP table even consulted by the sw stack at all - I
>> > dont think so (apart from drivers).
>> 
>> Not directly, but at least ocelot (or in fact felix) does set
>> skb->priority based on the QoS class from the Extraction Frame Header.
>> So the stack does end up consulting and meaningfully using something
>> that was set based on the dcbnl APP table.
>> 
>> In this sense, for ocelot, there is a real overlap between skb->priority
>> being initially set based on ocelot_xfh_get_qos_class(), and later being
>> overwritten based on the QoS maps of a VLAN interface.
>
> Right, so VLAN QoS maps currently takes precedence, if somebody would choose
> to add a tagged vlan interface on-top of a physical interface with existing
> PCP prioritization - is this a real problem, or just a question of configuration?

We have the same deal going on with TC BTW. Whatever prioritization is
transferred from HW to SW is lost when the packet is passed through the
SW TC rules.

And at least on Spectrum, we don't even have a way to transfer the
priority to SW, as far as I know. So in this sense it's exactly like
DCB, where the in-HW prioritization is completely separate from the SW
one. Except that all DCB APP rules are "skip_sw" and can't not be.