Message-ID: <CA+h21ho=r5i1ifFMPF1iTn3upCBkc-SMMFS7whqJ+utvXpHCQQ@mail.gmail.com>
Date:   Sat, 8 Feb 2020 15:32:06 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: VLAN retagging for packets switched between 2 certain ports

Hi Ido,

On Fri, 7 Feb 2020 at 19:43, Ido Schimmel <idosch@...sch.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@...il.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

Powered by blists - more mailing lists