| Message ID | 20190915020003.27926-5-olteanv@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
| Series | tc-taprio offload for SJA1105 DSA | expand |
On 9/14/2019 7:00 PM, Vladimir Oltean wrote: > This is a preparation patch for the tc-taprio offload (and potentially > for other future offloads such as tc-mqprio). > > 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. > > Unfortunately the switch doesn't look at the VLAN PCP in the case of > management traffic to/from the CPU (link-local frames at > 01-80-C2-xx-xx-xx or 01-1B-19-xx-xx-xx) so we can't alter the > transmission queue of this type of traffic on a frame-by-frame basis. It > is only selected through the "hostprio" setting which ATM is harcoded in > the driver to 7. > > Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
From: Vladimir Oltean <olteanv@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 generally use u32 filter and skbedit queue_mapping action to achieve this. --- Thanks, Jose Miguel Abreu
Hi Jose, On Sun, 15 Sep 2019 at 19:41, Jose Abreu <Jose.Abreu@synopsys.com> wrote: > > From: Vladimir Oltean <olteanv@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
diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c index d8cff0107ec4..108f62c27c28 100644 --- a/drivers/net/dsa/sja1105/sja1105_main.c +++ b/drivers/net/dsa/sja1105/sja1105_main.c @@ -384,7 +384,9 @@ static int sja1105_init_general_params(struct sja1105_private *priv) /* Disallow dynamic changing of the mirror port */ .mirr_ptacu = 0, .switchid = priv->ds->index, - /* Priority queue for link-local frames trapped to CPU */ + /* Priority queue for link-local management frames + * (both ingress to and egress from CPU - PTP, STP etc) + */ .hostprio = 7, .mac_fltres1 = SJA1105_LINKLOCAL_FILTER_A, .mac_flt1 = SJA1105_LINKLOCAL_FILTER_A_MASK, @@ -1711,6 +1713,9 @@ static int sja1105_setup(struct dsa_switch *ds) */ ds->vlan_filtering_is_global = true; + /* Advertise the 8 egress queues */ + ds->num_tx_queues = SJA1105_NUM_TC; + /* The DSA/switchdev model brings up switch ports in standalone mode by * default, and that means vlan_filtering is 0 since they're not under * a bridge, so it's safe to set up switch tagging at this time. diff --git a/net/dsa/tag_sja1105.c b/net/dsa/tag_sja1105.c index 47ee88163a9d..9c9aff3e52cf 100644 --- a/net/dsa/tag_sja1105.c +++ b/net/dsa/tag_sja1105.c @@ -89,7 +89,8 @@ static struct sk_buff *sja1105_xmit(struct sk_buff *skb, struct dsa_port *dp = dsa_slave_to_port(netdev); struct dsa_switch *ds = dp->ds; u16 tx_vid = dsa_8021q_tx_vid(ds, dp->index); - u8 pcp = skb->priority; + u16 queue_mapping = skb_get_queue_mapping(skb); + u8 pcp = netdev_txq_to_tc(netdev, queue_mapping); /* Transmitting management traffic does not rely upon switch tagging, * but instead SPI-installed management routes. Part 2 of this
This is a preparation patch for the tc-taprio offload (and potentially for other future offloads such as tc-mqprio). 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. Unfortunately the switch doesn't look at the VLAN PCP in the case of management traffic to/from the CPU (link-local frames at 01-80-C2-xx-xx-xx or 01-1B-19-xx-xx-xx) so we can't alter the transmission queue of this type of traffic on a frame-by-frame basis. It is only selected through the "hostprio" setting which ATM is harcoded in the driver to 7. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> --- Changes since v2: - None. Changes since v1: - None, but the use of netdev_txq_to_tc is now finally correct after adjusting the gate_mask meaning in the taprio offload structure. Changes since RFC: - None. drivers/net/dsa/sja1105/sja1105_main.c | 7 ++++++- net/dsa/tag_sja1105.c | 3 ++- 2 files changed, 8 insertions(+), 2 deletions(-)