netdev - Re: [PATCH v4 net-next 4/6] net: dsa: sja1105: Advertise the 8 TX queues

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: <CA+h21hrDf0Cmo+S4OGwPcbcyMD9uKbeR0Qh3pimRqKKL0ifhDA@mail.gmail.com>
Date:   Sun, 15 Sep 2019 20:28:28 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Jose Abreu <Jose.Abreu@...opsys.com>
Cc:     "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "vedang.patel@...el.com" <vedang.patel@...el.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        "weifeng.voon@...el.com" <weifeng.voon@...el.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "m-karicheri2@...com" <m-karicheri2@...com>,
        "ilias.apalodimas@...aro.org" <ilias.apalodimas@...aro.org>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
        "kurt.kanzenbach@...utronix.de" <kurt.kanzenbach@...utronix.de>,
        "joergen.andreasen@...rochip.com" <joergen.andreasen@...rochip.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 net-next 4/6] net: dsa: sja1105: Advertise the 8 TX queues

Hi Jose,

On Sun, 15 Sep 2019 at 19:41, Jose Abreu <Jose.Abreu@...opsys.com> wrote:
>
> From: Vladimir Oltean <olteanv@...il.com>
> Date: Sep/15/2019, 03:00:01 (UTC+00:00)
>
> > Instead of looking directly at skb->priority during xmit, let's get the
> > netdev queue and the queue-to-traffic-class mapping, and put the
> > resulting traffic class into the dsa_8021q PCP field. The switch is
> > configured with a 1-to-1 PCP-to-ingress-queue-to-egress-queue mapping
> > (see vlan_pmap in sja1105_main.c), so the effect is that we can inject
> > into a front-panel's egress traffic class through VLAN tagging from
> > Linux, completely transparently.
>
> Wouldn't it be better to just rely on skb queue mapping as per userspace
> settings ? I mean this way you cant create some complex scenarios
> without having the VLAN ID need.
>

I think I need to clarify the "without having the VLAN ID need" portion.
This is a DSA switch, and the thing that all these switches have in
common is that their data path is connected to the host system through
an Ethernet port pair (as opposed to e.g. DMA and real queues).
When you send a frame from the host through that Ethernet port, the
switch's natural tendency is to forward/flood it according to FDB
rules, which may not be what you want to achieve (i.e. you may want to
xmit on a specific front-panel port only, to achieve a 'port
multiplier' behavior out of it). Switch vendors achieve that by using
a proprietary frame header which indicates stuff such as: egress port,
QoS priority, etc. The host adds this tag to frames sent towards the
switch, and the switch consumes it.
In the case of sja1105, the frame tagging format is actually
'open-spec', e.g. it is an actual VLAN header, just with a custom
EtherType. Hence the QoS priority in this tagging format is the PCP
field. Other DSA switch vendors still have a 'priority' field in their
tagging format, even though it is not PCP.
So to answer your question, I do need VLAN tagging either way, for
even more basic reasons. But it is VLAN only from the switch's
hardware view. From the operating system's view it is no different
than populating the 'priority' field of any other DSA frame tagger.

> I generally use u32 filter and skbedit queue_mapping action to achieve
> this.
>

The trouble with relying on 'queue_mapping' only is that it's too
open-ended: what does a queue really mean for an Ethernet-managed
switch?
In my interpretation of the mqprio/taprio offloads, the netdev queue
is only an intermediary representation between the qdisc and the NIC's
traffic classes. Now that makes sense, because even though the switch
xmit procedure isn't multi-queue, there is still strict egress
prioritization based on the traffic class mapping (inferred from VLAN
PCP).
I have no idea how people are managing multi-queue net devices without
an mqprio-type offload, if those netdev queues are not of equal
priority. Technically, if you use the 'skbedit queue_mapping' action
with this switch, it is your choice how you manage the
net_device->tc_to_txq array, keeping in mind that tc 7 will have
higher priority over tc 6. Alternatively, you can still use an
mqprio-type offload, specify "num_tc 8 map 0 1 2 3 5 6 7 queues 1@0
1@1 1@2 1@3 1@4 1@5 1@6 1@7", and then just use the 'skbedit priority'
action. Then things would just work.
So I am just using the 'queues' term for this switch to express the
strict priority scheduler. There isn't really any benefit to having
more than one netdev queue exposed per traffic class.

> ---
> Thanks,
> Jose Miguel Abreu

Hope this clarifies,
-Vladimir