* VLAN retagging for packets switched between 2 certain ports
@ 2020-02-06 9:02 Vladimir Oltean
2020-02-06 9:32 ` Vladimir Oltean
0 siblings, 1 reply; 5+ messages in thread
From: Vladimir Oltean @ 2020-02-06 9:02 UTC (permalink / raw)
To: netdev
Hi netdev,
I am interested in modeling the following classifier/action with tc filters:
- Match packets with VID N received on port A and going towards port B
- Replace VID with M
Some hardware (DSA switch) I am working on supports this, so it would
be good if I could model this with tc in a way that can be offloaded.
In man tc-flower I found the following matches:
indev ifname
Match on incoming interface name. Obviously this makes
sense only for forwarded flows. ifname is the name of an interface
which must exist at the time of tc invocation.
vlan_id VID
Match on vlan tag id. VID is an unsigned 12bit value in
decimal format.
And there is a generic "vlan" action (man tc-vlan) that supports the
"modify" command.
Judging from this syntax, I would need to add a tc-flower rule on the
egress qdisc of swpB, with indev swpA and vlan_id N.
But what should I do if I need to do VLAN retagging towards the CPU
(where DSA does not give me a hook for attaching tc filters)?
Thanks,
-Vladimir
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: VLAN retagging for packets switched between 2 certain ports 2020-02-06 9:02 VLAN retagging for packets switched between 2 certain ports Vladimir Oltean @ 2020-02-06 9:32 ` Vladimir Oltean 2020-02-07 17:43 ` Ido Schimmel 2020-02-10 14:34 ` Ido Schimmel 0 siblings, 2 replies; 5+ messages in thread From: Vladimir Oltean @ 2020-02-06 9:32 UTC (permalink / raw) To: netdev On Thu, 6 Feb 2020 at 11:02, Vladimir Oltean <olteanv@gmail.com> wrote: > > Hi netdev, > > I am interested in modeling the following classifier/action with tc filters: > - Match packets with VID N received on port A and going towards port B > - Replace VID with M > > Some hardware (DSA switch) I am working on supports this, so it would > be good if I could model this with tc in a way that can be offloaded. > In man tc-flower I found the following matches: > indev ifname > Match on incoming interface name. Obviously this makes > sense only for forwarded flows. ifname is the name of an interface > which must exist at the time of tc invocation. > vlan_id VID > Match on vlan tag id. VID is an unsigned 12bit value in > decimal format. > > And there is a generic "vlan" action (man tc-vlan) that supports the > "modify" command. > > Judging from this syntax, I would need to add a tc-flower rule on the > egress qdisc of swpB, with indev swpA and vlan_id N. > But what should I do if I need to do VLAN retagging towards the CPU > (where DSA does not give me a hook for attaching tc filters)? > > Thanks, > -Vladimir While I don't want to influence the advice that I get, I tried to see this from the perspective of "what would a non-DSA device do?". So what I think would work for me is: - For VLAN retagging of autonomously forwarded flows (between 2 front-panel ports) I can do the egress filter with indev that I mentioned above. - For VLAN retagging towards the CPU, I can just attach the filter to the ingress qdisc and not specify an indev at all. The idea being that this filter will match on locally terminated packets and not on all packets received on this port. Would this be confusing? -Vladimir ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: VLAN retagging for packets switched between 2 certain ports 2020-02-06 9:32 ` Vladimir Oltean @ 2020-02-07 17:43 ` Ido Schimmel 2020-02-08 13:32 ` Vladimir Oltean 2020-02-10 14:34 ` Ido Schimmel 1 sibling, 1 reply; 5+ messages in thread From: Ido Schimmel @ 2020-02-07 17:43 UTC (permalink / raw) To: Vladimir Oltean; +Cc: netdev Hi Vladimir, On Thu, Feb 06, 2020 at 11:32:52AM +0200, Vladimir Oltean wrote: > On Thu, 6 Feb 2020 at 11:02, Vladimir Oltean <olteanv@gmail.com> wrote: > > > > Hi netdev, > > > > I am interested in modeling the following classifier/action with tc filters: > > - Match packets with VID N received on port A and going towards port B > > - Replace VID with M > > > > Some hardware (DSA switch) I am working on supports this, so it would > > be good if I could model this with tc in a way that can be offloaded. > > In man tc-flower I found the following matches: > > indev ifname > > Match on incoming interface name. Obviously this makes > > sense only for forwarded flows. ifname is the name of an interface > > which must exist at the time of tc invocation. > > vlan_id VID > > Match on vlan tag id. VID is an unsigned 12bit value in > > decimal format. > > > > And there is a generic "vlan" action (man tc-vlan) that supports the > > "modify" command. > > > > Judging from this syntax, I would need to add a tc-flower rule on the > > egress qdisc of swpB, with indev swpA and vlan_id N. > > But what should I do if I need to do VLAN retagging towards the CPU > > (where DSA does not give me a hook for attaching tc filters)? > > > > Thanks, > > -Vladimir > > While I don't want to influence the advice that I get, I tried to see > this from the perspective of "what would a non-DSA device do?". > So what I think would work for me is: > - For VLAN retagging of autonomously forwarded flows (between 2 > front-panel ports) I can do the egress filter with indev that I > mentioned above. > - For VLAN retagging towards the CPU, I can just attach the filter to > the ingress qdisc and not specify an indev at all. The idea being that > this filter will match on locally terminated packets and not on all > packets received on this port. > Would this be confusing? Yes. The correct way to handle this would be to add a netdev to represent the CPU port (switch side) and add the filter on its egress qdisc. In addition to your use case, this also allows us to solve other use cases: 1. Control Plane Policing (COPP): Policing of traffic going to the CPU. By installing relevant filters with police/drop actions. 2. Scheduling traffic towards the CPU: By appropriately configuring the egress qdisc, just like for external ports. I hope to introduce a netdev for the CPU port in mlxsw to solve the first use case in the upcoming months. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: VLAN retagging for packets switched between 2 certain ports 2020-02-07 17:43 ` Ido Schimmel @ 2020-02-08 13:32 ` Vladimir Oltean 0 siblings, 0 replies; 5+ messages in thread From: Vladimir Oltean @ 2020-02-08 13:32 UTC (permalink / raw) To: Ido Schimmel; +Cc: netdev Hi Ido, On Fri, 7 Feb 2020 at 19:43, Ido Schimmel <idosch@idosch.org> wrote: > > Hi Vladimir, > > On Thu, Feb 06, 2020 at 11:32:52AM +0200, Vladimir Oltean wrote: > > On Thu, 6 Feb 2020 at 11:02, Vladimir Oltean <olteanv@gmail.com> wrote: > > > > > > Hi netdev, > > > > > > I am interested in modeling the following classifier/action with tc filters: > > > - Match packets with VID N received on port A and going towards port B > > > - Replace VID with M > > > > > > Some hardware (DSA switch) I am working on supports this, so it would > > > be good if I could model this with tc in a way that can be offloaded. > > > In man tc-flower I found the following matches: > > > indev ifname > > > Match on incoming interface name. Obviously this makes > > > sense only for forwarded flows. ifname is the name of an interface > > > which must exist at the time of tc invocation. > > > vlan_id VID > > > Match on vlan tag id. VID is an unsigned 12bit value in > > > decimal format. > > > > > > And there is a generic "vlan" action (man tc-vlan) that supports the > > > "modify" command. > > > > > > Judging from this syntax, I would need to add a tc-flower rule on the > > > egress qdisc of swpB, with indev swpA and vlan_id N. > > > But what should I do if I need to do VLAN retagging towards the CPU > > > (where DSA does not give me a hook for attaching tc filters)? > > > > > > Thanks, > > > -Vladimir > > > > While I don't want to influence the advice that I get, I tried to see > > this from the perspective of "what would a non-DSA device do?". > > So what I think would work for me is: > > - For VLAN retagging of autonomously forwarded flows (between 2 > > front-panel ports) I can do the egress filter with indev that I > > mentioned above. > > - For VLAN retagging towards the CPU, I can just attach the filter to > > the ingress qdisc and not specify an indev at all. The idea being that > > this filter will match on locally terminated packets and not on all > > packets received on this port. > > Would this be confusing? > > Yes. The correct way to handle this would be to add a netdev to > represent the CPU port (switch side) and add the filter on its egress > qdisc. In addition to your use case, this also allows us to solve other > use cases: > > 1. Control Plane Policing (COPP): Policing of traffic going to the CPU. > By installing relevant filters with police/drop actions. > 2. Scheduling traffic towards the CPU: By appropriately configuring the > egress qdisc, just like for external ports. > > I hope to introduce a netdev for the CPU port in mlxsw to solve the > first use case in the upcoming months. I understand your point of view, but I personally don't think that adding a netdev for the CPU port is coherent with the interface that DSA is trying to expose. Sure, at times this design has perhaps limited what has been done with DSA, but that doesn't mean that exposing that net device would be the right solution. - Why is configuring an egress qdisc on the CPU port less confusing? As far as I'm aware, an egress qdisc offload should do the same thing as the non-offloaded version, but in the case of the CPU port, there isn't any "egress" from software perspective to speak of. As for ingress: what would tcpdump show? Nothing, probably. - If we add that CPU port net device, should traffic be allowed to pass between the front-panel ports and the CPU port by default? (of course the answer is yes, but: ) Should that CPU port be part of the bridge or not? It should be, but it won't be. So not having the net device avoids that problem and a bunch of others. Thanks, -Vladimir ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: VLAN retagging for packets switched between 2 certain ports 2020-02-06 9:32 ` Vladimir Oltean 2020-02-07 17:43 ` Ido Schimmel @ 2020-02-10 14:34 ` Ido Schimmel 1 sibling, 0 replies; 5+ messages in thread From: Ido Schimmel @ 2020-02-10 14:34 UTC (permalink / raw) To: Vladimir Oltean; +Cc: netdev On Thu, Feb 06, 2020 at 11:32:52AM +0200, Vladimir Oltean wrote: > On Thu, 6 Feb 2020 at 11:02, Vladimir Oltean <olteanv@gmail.com> wrote: > > > > Hi netdev, > > > > I am interested in modeling the following classifier/action with tc filters: > > - Match packets with VID N received on port A and going towards port B > > - Replace VID with M > > > > Some hardware (DSA switch) I am working on supports this, so it would > > be good if I could model this with tc in a way that can be offloaded. > > In man tc-flower I found the following matches: > > indev ifname > > Match on incoming interface name. Obviously this makes > > sense only for forwarded flows. ifname is the name of an interface > > which must exist at the time of tc invocation. > > vlan_id VID > > Match on vlan tag id. VID is an unsigned 12bit value in > > decimal format. > > > > And there is a generic "vlan" action (man tc-vlan) that supports the > > "modify" command. > > > > Judging from this syntax, I would need to add a tc-flower rule on the > > egress qdisc of swpB, with indev swpA and vlan_id N. > > But what should I do if I need to do VLAN retagging towards the CPU > > (where DSA does not give me a hook for attaching tc filters)? > > > > Thanks, > > -Vladimir > > While I don't want to influence the advice that I get, I tried to see > this from the perspective of "what would a non-DSA device do?". > So what I think would work for me is: > - For VLAN retagging of autonomously forwarded flows (between 2 > front-panel ports) I can do the egress filter with indev that I > mentioned above. > - For VLAN retagging towards the CPU, I can just attach the filter to > the ingress qdisc and not specify an indev at all. The idea being that > this filter will match on locally terminated packets and not on all > packets received on this port. > Would this be confusing? Why don't you just use "skip_hw" flag? The filter will not be installed in hardware and will only match locally received packets. Isn't this what you want? ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-02-10 14:34 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-02-06 9:02 VLAN retagging for packets switched between 2 certain ports Vladimir Oltean 2020-02-06 9:32 ` Vladimir Oltean 2020-02-07 17:43 ` Ido Schimmel 2020-02-08 13:32 ` Vladimir Oltean 2020-02-10 14:34 ` Ido Schimmel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).