Hi Jose, On Sun, 15 Sep 2019 at 19:41, Jose Abreu <jose.ab...@synopsys.com> wrote: > > From: Vladimir Oltean <olte...@gmail.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
