Re: VLAN retagging for packets switched between 2 certain ports

[Ido Schimmel <idosch@idosch.org>]

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.