Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
CC:     "davem@davemloft.net" <davem@davemloft.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "allan.nielsen@microchip.com" <allan.nielsen@microchip.com>,
        "joergen.andreasen@microchip.com" <joergen.andreasen@microchip.com>,
        "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
        "vinicius.gomes@intel.com" <vinicius.gomes@intel.com>,
        "michael.chan@broadcom.com" <michael.chan@broadcom.com>,
        "saeedm@mellanox.com" <saeedm@mellanox.com>,
        "jiri@mellanox.com" <jiri@mellanox.com>,
        "idosch@mellanox.com" <idosch@mellanox.com>,
        "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>,
        "kuba@kernel.org" <kuba@kernel.org>, Po Liu <po.liu@nxp.com>,
        Leo Li <leoyang.li@nxp.com>
Subject: RE: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on
 vsc9959
Thread-Topic: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on
 vsc9959
Thread-Index: AQHXnhk3XLn1mK+aKEKIkxNIly6FZauNPsGAgAADucCAAAqfgIAAAG6ggAAFpICAAALSAIAAA8DQ
Date:   Tue, 31 Aug 2021 09:59:11 +0000
Message-ID: <DB8PR04MB57855C49E4564A8B79C991C3F0CC9@DB8PR04MB5785.eurprd04.prod.outlook.com>
References: <20210831034536.17497-1-xiaoliang.yang_1@nxp.com>
 <20210831034536.17497-6-xiaoliang.yang_1@nxp.com>
 <20210831075450.u7smg5bibz3vvw4q@skbuf>
 <DB8PR04MB5785D9E678164B7CFE2A38CCF0CC9@DB8PR04MB5785.eurprd04.prod.outlook.com>
 <20210831084610.gadyyrkm4fwzf6hp@skbuf>
 <DB8PR04MB5785E37A5054FC94E4D6E7B5F0CC9@DB8PR04MB5785.eurprd04.prod.outlook.com>
 <20210831090754.3z7ihy3iqn6ixyhh@skbuf>
 <20210831091759.dacg377d7jsiuylp@skbuf>
In-Reply-To: <20210831091759.dacg377d7jsiuylp@skbuf>
Accept-Language: zh-CN, en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?lIr7wS9nQHZ1GGv6qrbVN9MgeJHz5AkGOHavuf7db18pZhbRa7VP1hXljd9X?=
 =?us-ascii?Q?/Ps4j1nPZ+iMoX2ZZSWR38kNuX4dcrV1HCt/502KjoW+9H1Mz9zdhneY8KAK?=
 =?us-ascii?Q?wHBz+4a/n0V5xoagrY+duQ510QLll92HhkGDhcC/L/j2GjCvo6DQg7fmxdMX?=
 =?us-ascii?Q?TpkTCF5i9iLzCJJlUyxau9AhzRNpRvsNa64/YeEx0AldrO8VGFrlDCpHOeW7?=
 =?us-ascii?Q?sb5clV2i0mPrRoJWOBxMoa/425jAlHoMKySFnedLfNs62zvf/GN1GRrkEsbP?=
 =?us-ascii?Q?5cca3Wulqt7U5pRhAL4kiUKf9pQm4jBwoaZEaZJ5a84mqZoorhiLlRYaiE8j?=
 =?us-ascii?Q?SIDpdfiVnWAO0+lrVhMTDkYjPjYTVigxC2gmEw821E1XaG9bOS9piOQuYif3?=
 =?us-ascii?Q?wZqJKH4499PHZJhrZGFydL0MYFrSW2mwGAMGq7aiLsFNCeUnHMvTkKlZfSEe?=
 =?us-ascii?Q?sz/RXEEGFGMUfrELXg24UqOfiWgSVzzpf1FKG3M14jEzvBJUbJSIhC9iU8jq?=
 =?us-ascii?Q?zpisd8h5ZWAkYOVF6fZtSGQnzDwVyIULmDmxeVYORWEvBbcJjxnkqziMqOd5?=
 =?us-ascii?Q?MaEJdv893+GvCFu6e/OtT4HOaCS72p9jvN9eZ89KwISEtYE2hCtLb+Ve2r8g?=
 =?us-ascii?Q?4iDTa/uk3IckP0s9/LzYFSMoTR5glBd+pebCuB0Z+bva6hzRF3EN25Y8SF/H?=
 =?us-ascii?Q?gyWungWPFVCDJDW0u8sOPH9AIS6H1c3L3KXsyQYjzYD1ZqGFwVFhjHHLup3C?=
 =?us-ascii?Q?lxSRzUjW9oH7eo3D4mPKN2qS3M2p2fHXL3bQwaie1OvdqOhv6YolE3D/Kt3H?=
 =?us-ascii?Q?2xTaDi785nJbhq0ySIvWc+WFw5jVAd7izA8YvpI0t96TkG1dE8gBBtkol+LV?=
 =?us-ascii?Q?NF5crQQdY84ICsH9bVU3tgShVZ3/RKp1fM1OgAp7NUSXE9Q0284vUi3Hb/uw?=
 =?us-ascii?Q?s/uqb2BRrk3PnkW7Jmlzgdai+HQ5fJaEnlSYj6wntcljscUwHa1yHNPSUX3i?=
 =?us-ascii?Q?Kqq4whCDMJVl67fGdp2uzEtvRBZVbVzE+C7RhAMnadDo0ECK02S/++ipazIy?=
 =?us-ascii?Q?u1FH4PIS19aTb2gs9odmDanW/86XZabnFO9pQALiuAQ0ejwo+IthH9peCdAO?=
 =?us-ascii?Q?CxkYPpheGQhH48OlVIhSeJ+mmCu7823lY39llsbRnW/AkM+qm+g2ai8wOgHI?=
 =?us-ascii?Q?8Vm3CRZ8gg1gRUOiwu/fp6Vw5TFA5ENKjctRH1TkKNbNybuyFCvZ0u81LWzZ?=
 =?us-ascii?Q?lhNAEO8PPEBQ55lhym//Jcq5GPL0Ios5tqbmJUCv/8Ja4k4x3szY1iAV+XR1?=
 =?us-ascii?Q?J48fXgVts9J6iK4c+hYbC75V?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB8PR04MB5785.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3cfda187-7a61-497b-2278-08d96c65fbc5
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2021 09:59:11.9943
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KS2ugObG2LCS+DNqvSC6dOxxLq0EAW3v1kH/W5Aj+6pHmK5vhQYIynTGAi+27/napf6aTxHc+jZqml3kBU/YRB2bCWdie9+bEG7LBsZB+OM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR04MB5497
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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?
>=20
> In sja1105's implementation of PSFP (which is not standard-compliant as i=
t is
> based on TTEthernet, but makes more sense anyway), the Virtual Links (SFI=
Ds
> 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 multi=
ple
> 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
>=20
> 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 w=
ay
> at it.

Yes, Using redirect action can give PSFP filter a forward port to add MAC t=
able entry. But it also has the issue that when using "bridge fdb del" to d=
elete the MAC entry will cause the tc-filter rule not working.