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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230307164614.jy2mzxvk3xgc4z7b@skbuf>
Date:   Tue, 7 Mar 2023 18:46:14 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Woojung Huh <woojung.huh@...rochip.com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        UNGLinuxDriver@...rochip.com, Eric Dumazet <edumazet@...gle.com>,
        kernel@...gutronix.de, Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next v1 2/2] net: dsa: microchip: add ETS Qdisc
 support for KSZ9477 series

On Mon, Mar 06, 2023 at 05:35:42PM +0100, Oleksij Rempel wrote:
> > So what does the user gain using tc-ets over tc-mqprio? That has a way
> > to set up strict prioritization and prio:tc maps as well, and to my
> > knowledge mqprio is vastly more popular in non-DCB setups than tc-ets.
> > The only thing is that with mqprio, AFAIK, the round robin between TXQs
> > belonging to the same traffic class is not weighted.
> 
> Do mqprio already supports strict prio mode? net-next was not supporting
> this back for two weeks. I do not care what to use, my motivation was based on
> following points:
> - tc-ets supports strict prio. mqprio need to be extended to do this
> - tc-ets refers to IEEE 802.1Q specification, so i feel safe
>   and do not need to invent new things.
> - mqprio automatically creates software queues, but it seems to not
>   provide any advantage for a typical bridged DSA setup. For example
>   i can use queue mapping only for traffic from CPU to external DSA port
>   but can't use multi queue advantages of CPU MAC for same traffic  (do I'm
>   missing something). For bridged traffic i'll need to use HW offloading any
>   way.

Sorry, my inbox is a mess and I forgot to respond to this.
What do you mean tc-mqprio doesn't support strict priority? Strict
priority between traffic classes is what it *does* (the "prio" in the name),
although without hardware offload, the prioritization isn't enforced anywhere.
Perhaps I'm misunderstanding what you mean?

For strict prioritization using multi-queue on the DSA master you should
be able to set up a separate Qdisc.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ