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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 9 Sep 2022 12:11:50 +0000 From: Vladimir Oltean <vladimir.oltean@....com> To: "Daniel.Machon@...rochip.com" <Daniel.Machon@...rochip.com> CC: "Allan.Nielsen@...rochip.com" <Allan.Nielsen@...rochip.com>, "kuba@...nel.org" <kuba@...nel.org>, "petrm@...dia.com" <petrm@...dia.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>, "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>, "maxime.chevallier@...tlin.com" <maxime.chevallier@...tlin.com>, "roopa@...dia.com" <roopa@...dia.com> Subject: Re: Basic PCP/DEI-based queue classification On Wed, Sep 07, 2022 at 07:57:08PM +0000, Daniel.Machon@...rochip.com wrote: > 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? No, I don't think it's a real problem. I think it can be reasonably seen as a per-VLAN override of the port-based default. > > The problem with the ingress-qos-map and egress-qos-map from 802.1Q that > > I see is that they allow for per-VID prioritization, which is way more > > fine grained than what we need. This, plus the fact that bridge VLANs > > don't have this setting, only termination (8021q) VLANs do. How about an > > ingress-qos-map and an egress-qos-map per port rather than per VID, > > potentially even a bridge_slave netlink attribute, offloadable through > > switchdev? We could make the bridge input fast path alter skb->priority > > for the VLAN-tagged code paths, and this could give us superior > > semantics compared to putting this non-standardized knob in the hardware > > only dcbnl. > > This is a valid alternative solution to dcbnl, although this seems to be a > much more complex solution, to something that is easily solved in dcbnl, > and actually is in-line with what dcbnl already does. On-top of this, the > notion of 'trust' has also been raised by this topic. It makes a lot of sense > to me to add APP selector trust and trust order to dcbnl. This is the solution > that I have been implementing lately, and is ready for posting very soon. Ok, I'll take a look at what your implementation proposes.
Powered by blists - more mailing lists