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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 25 Aug 2020 01:57:14 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     kuba@...nel.org, kurt@...utronix.de, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org, robh+dt@...nel.org,
        devicetree@...r.kernel.org, bigeasy@...utronix.de,
        richardcochran@...il.com, kamil.alkhouri@...offenburg.de,
        ilias.apalodimas@...aro.org, ivan.khoronzhuk@...aro.org,
        vinicius.gomes@...el.com, xiaoliang.yang_1@....com, Po.Liu@....com
Subject: Re: [PATCH v3 0/8] Hirschmann Hellcreek DSA driver

On Mon, Aug 24, 2020 at 03:35:18PM -0700, David Miller wrote:
> From: Vladimir Oltean <olteanv@...il.com>
> Date: Tue, 25 Aug 2020 01:02:03 +0300
> 
> > Just my comment on patch 5/8 about netdev->tc_to_txq. There are 2
> > distinct things about that:
> > - accessing struct net_device directly hurts the DSA model a little bit.
> > - I think there's some confusion regarding the use of netdev->tc_to_txq
> >   itself. I don't think that's the right place to setup a VLAN PCP to
> >   traffic class mapping. That's simply "what traffic class does each
> >   netdev queue have". I would even go as far as say that Linux doesn't
> >   support a VLAN PCP to TC mapping (similar to the DSCP to TC mapping
> >   from the DCB ops) at all, except for the ingress-qos-map and
> >   egress-qos-map of the 8021q driver, which can't be offloaded and don't
> >   map nicely over existing hardware anyway (what hardware has an
> >   ingress-qos-map and an egress-qos-map per individual VLAN?!).
> >   Although I do really see the need for having a mapping between VLAN
> >   PCP and traffic class, I would suggest Kurt to not expose this through
> >   taprio/mqprio (hardcode the PCP mapping as 1-to-1 with TC, as other
> >   drivers do), and let's try to come up separately with an abstraction
> >   for that.
> 
> Agreed, Kurt can you repost this series without the TAPRIO support for
> now since it's controversial and needs more discussion and changes?
> 
> Thank you.

To be clear, the most important part of the taprio qdisc offload
(setting up the gate control list) does not need to be postponed. It's
just the VLAN PCP mapping that is a bit controversial.

Thanks,
-Vladimir

Powered by blists - more mailing lists