[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB8PR04MB57855C49E4564A8B79C991C3F0CC9@DB8PR04MB5785.eurprd04.prod.outlook.com>
Date: Tue, 31 Aug 2021 09:59:11 +0000
From: Xiaoliang Yang <xiaoliang.yang_1@....com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"allan.nielsen@...rochip.com" <allan.nielsen@...rochip.com>,
"joergen.andreasen@...rochip.com" <joergen.andreasen@...rochip.com>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
"vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
"michael.chan@...adcom.com" <michael.chan@...adcom.com>,
"saeedm@...lanox.com" <saeedm@...lanox.com>,
"jiri@...lanox.com" <jiri@...lanox.com>,
"idosch@...lanox.com" <idosch@...lanox.com>,
"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
"kuba@...nel.org" <kuba@...nel.org>, Po Liu <po.liu@....com>,
Leo Li <leoyang.li@....com>
Subject: RE: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on
vsc9959
On Tue, Aug 31, 2021 at 17:18:00PM +0300, Vladimir Oltean wrote:
> > > > I think in previous versions you were automatically installing a
> > > > static MAC table entry when one was not present (either it was
> > > > absent, or the entry was dynamically learned). Why did that change?
> > >
> > > The PSFP gate and police action are set on ingress port, and "
> > > tc-filter" has no parameter to set the forward port for the filtered
> > > stream. And I also think that adding a FDB mac entry in tc-filter
> > > command is not good.
> >
> > Fair enough, but if that's what you want, we'll need to think a lot
> > harder about how this needs to be modeled.
> >
> > Would you not have to protect against a 'bridge fdb del' erasing your
> > MAC table entry after you've set up the TSN stream on it?
> >
> > Right now, DSA does not even call the driver's .port_fdb_del method
> > from atomic context, just from deferred work context. So even if you
> > wanted to complain and say "cannot remove FDB entry until SFID stops
> > pointing at it", that would not be possible with today's code structure.
> >
> > And what would you do if the bridge wants to delete the FDB entry
> > irrevocably, like when the user wants to delete the bridge in its
> > entirety? You would still remain with filters in tc which are not
> > backed by any MAC table entry.
> >
> > Hmm..
> > Either the TSN standards for PSFP and FRER are meant to be implemented
> > within the bridge driver itself, and not as part of tc, or the
> > Microchip implementation is very weird for wiring them into the bridge MAC
> table.
> >
> > Microchip people, any comments?
>
> In sja1105's implementation of PSFP (which is not standard-compliant as it is
> based on TTEthernet, but makes more sense anyway), the Virtual Links (SFIDs
> here) are not based on the FDB table, but match only on the given source port.
> They behave much more like ACL entries.
> The way I've modeled them in Linux was to force the user to offload multiple
> actions for the same tc-filter, both a redirect action and a police/gate action.
> https://www.kernel.org/doc/html/latest/networking/dsa/sja1105.html#time-b
> ased-ingress-policing
>
> I'm not saying this helps you, I'm just saying maybe the Microchip
> implementation is strange, but then again, I might be looking the wrong way
> at it.
Yes, Using redirect action can give PSFP filter a forward port to add MAC table entry. But it also has the issue that when using "bridge fdb del" to delete the MAC entry will cause the tc-filter rule not working.
Powered by blists - more mailing lists