[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200210143400.GA185791@splinter>
Date: Mon, 10 Feb 2020 16:34:00 +0200
From: Ido Schimmel <idosch@...sch.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: netdev <netdev@...r.kernel.org>
Subject: Re: VLAN retagging for packets switched between 2 certain ports
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?
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?
Powered by blists - more mailing lists