RE: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on vsc9959

[Xiaoliang Yang]

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.