netdev - Re: [PATCH v3 0/8] Hirschmann Hellcreek DSA driver

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]

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