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:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Vinicius Costa Gomes <vinicius.gomes@intel.com>
CC:     Xiaoliang Yang <xiaoliang.yang_1@nxp.com>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "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>,
        "ivan.khoronzhuk@linaro.org" <ivan.khoronzhuk@linaro.org>,
        "allan.nielsen@microchip.com" <allan.nielsen@microchip.com>,
        "joergen.andreasen@microchip.com" <joergen.andreasen@microchip.com>,
        "jhs@mojatatu.com" <jhs@mojatatu.com>
Subject: Re: [EXT] Re: [RFC, net-next] net: qos: introduce a frer action to
 implement 802.1CB
Thread-Topic: [EXT] Re: [RFC, net-next] net: qos: introduce a frer action to
 implement 802.1CB
Thread-Index: AQHXtFznyGH2JvuT50mNvd/a5fV2Jau6CVIAgADGvQCAA5paAIAAB+EAgAAEfQA=
Date:   Fri, 1 Oct 2021 18:11:29 +0000
Message-ID: <20211001181128.goytn4jhicqx7ehk@skbuf>
References: <20210928114451.24956-1-xiaoliang.yang_1@nxp.com>
 <87czos9vnj.fsf@linux.intel.com>
 <DB8PR04MB5785F3128FEB1FB1B2F9AC0DF0A99@DB8PR04MB5785.eurprd04.prod.outlook.com>
 <87lf3cfyfj.fsf@intel.com> <20211001175524.3sa2m3occzham5og@skbuf>
In-Reply-To: <20211001175524.3sa2m3occzham5og@skbuf>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?PeCVrKq7wMNhllltvEjFllGq4m5P+JOYSh0P4gNBU0gcXdU4I9JhcskGkrJL?=
 =?us-ascii?Q?h1Ruzkeqy7PV/nvf5vautCwkeKCClqDcCu/TFuiFRBWIGNkFKSYUre0h5IyV?=
 =?us-ascii?Q?Ooc8fuvKYH9KW4f61exIwufark9QVaOWDjiY2B1DuY5h2eOTQbbnly4EbB0S?=
 =?us-ascii?Q?u2dIZsrMTHMy1azWDwygkdAfeE9DFnmvmWR7UpfDeqWIFOvNT60S9VrxU/fn?=
 =?us-ascii?Q?EtzfMi0A/zBCYd+G3ayph4nuJPbKb8GiIRNzxW8gdOf4i+UP7NO+YQ6p8TZ8?=
 =?us-ascii?Q?RG0kEqsxqtYv27SYoSbjGGIsZBDZaCrd4vMIst64eLhQMDBNuLLdTZM/HcjL?=
 =?us-ascii?Q?dnCpOmaN9j7ESjydnWxCD9EbtPX24hoMoUsRMJZlQhPCPa/il3h7VZ+Fq9II?=
 =?us-ascii?Q?6hEF0kl5Vi3LKgqi+SsT29KsI54DNdw9za5vFtOYjH9VVbgUTvSPTH60wdi7?=
 =?us-ascii?Q?oApdsRV7BTKNrjvgojtBGftbzjnifMiUxSg/KjUP+geKxaSjTuySWM0WkewO?=
 =?us-ascii?Q?2LHv24pqf+xrzH2DtlRiJgTJwfZevXkoXF5vkEinyw7nmfuNAY20QzBAemd5?=
 =?us-ascii?Q?QqRqBLpGms6uRUcygZztYSSjuU/yM40GOjl/Um+gHcLgMrCkKevVdpZ0BidD?=
 =?us-ascii?Q?Ny5rYdHxQwDTSD6M2CwFGfv1aUD3sLKOzF09G+ahnALqes5qr3rYTDm0y9ag?=
 =?us-ascii?Q?UAJsb8T4lG0O7YlIryFpomON0vyrtrKADamlED9vxt504Y5nW1S5wZZEIkBt?=
 =?us-ascii?Q?59hI/+Sr559isLZiecPYWq37aRplPfmGzpqht4KWlTputKIg4xIaNYKQt6eO?=
 =?us-ascii?Q?0pzbW74jGYozDQoJ4TlQ3M715vjYvRG+tlN/6PKc3KDHgMD2T9ZZZlOTR23X?=
 =?us-ascii?Q?jKGNlQe8mihGwsIxPBSO0MsvY71RsDcRv3HsTRAnmIxTAX/K9YiHfC/SlQ8a?=
 =?us-ascii?Q?9PYa+VDyP53Z8b8lzWEba98JB5KHtX4AjMHcMZogimg/XkVreGpg9RuWGk7G?=
 =?us-ascii?Q?p+hJY/hsVGkog4F9sqmj9xsjlizL0/oR4PbsMzk3/p/r4rGBKUlUmh7CwUlI?=
 =?us-ascii?Q?jofBaViHFYKUtmQByGHDQE7gsf6LUL3qa36wOwsee6nXuboMBSLazI+edSN4?=
 =?us-ascii?Q?+jDsYST07DCy3xFoeisFf+yYBev5SbCTnj6uPkI8hdgjOLXFFpesqD+B2b4K?=
 =?us-ascii?Q?wDIJwz7wbrPR8ziruoqDgcNEDcxxrxvaRCx201AETfpL9Tnwz+7pdIRxR68p?=
 =?us-ascii?Q?DNxGZ0DxuVpWytW/3lysA2wZBtjmKw+9NF8v8LDVjjT2cvTXDMAGdWjtxqvQ?=
 =?us-ascii?Q?a6ldVYJg3vB/03IbeeTkU7YfzR4dpABvL8N14him3n6ndA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <005F40F4D741B44A81ED8BE11EE61669@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2ff67262-3daa-43b5-7dba-08d98506e41d
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 18:11:29.2522
 (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: vZkvZ+4bbgoln/GkyUtcdAzXnagMb/WNGgtsU+9troAM11tRjC2DaONz0k+lxeoLjvGqcvOqossT2RP5rmzuiw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5504
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Oct 01, 2021 at 08:55:24PM +0300, Vladimir Oltean wrote:
> On Fri, Oct 01, 2021 at 10:27:12AM -0700, Vinicius Costa Gomes wrote:
> > Xiaoliang Yang <xiaoliang.yang_1@nxp.com> writes:
> >=20
> > > Hi Vinicius,
> > >
> > > On Sep 29, 2021 at 6:35:59 +0000, Vinicius Costa Gomes wrote:
> > >> > This patch introduce a frer action to implement frame replication =
and
> > >> > elimination for reliability, which is defined in IEEE P802.1CB.
> > >> >
> > >>=20
> > >> An action seems, to me, a bit too limiting/fine grained for a frame =
replication
> > >> and elimination feature.
> > >>=20
> > >> At least I want to hear the reasons that the current hsr/prp support=
 cannot be
> > >> extended to support one more tag format/protocol.
> > >>=20
> > >> And the current name for the spec is IEEE 802.1CB-2017.
> > >>=20
> > > 802.1CB can be set on bridge ports, and need to use bridge forward
> > > Function as a relay system. It only works on identified streams,
> > > unrecognized flows still need to pass through the bridged network
> > > normally.
> >=20
> > This ("only on identified streams") is the strongest argument so far to
> > have FRER also as an action, in adition to the current hsr netdevice
> > approach.
> >=20
> > >
> > > But current hsr/prp seems only support two ports, and cannot use the
> > > ports in bridge. It's hard to implement FRER functions on current HSR
> > > driver.
> >=20
> > That the hsr netdevice only support two ports, I think is more a bug
> > than a design issue. Which will need to get fixed at some point.=20
>=20
> What do you mean 'a bug'? HSR and PRP, as protocols, use _two_ ports,
> see IEC 62439-3, that's where the "D" (doubly attached node) in DANH and
> DANP comes from. There's no TANH/TANH for "triply attached node".
> It doesn't scale.
>=20
> > Speaking of functions, one thing that might be interesting is trying to
> > see if it makes sense to make part of the current hsr functionality a
> > "library" so it can be used by tc-frer as well. (less duplication of
> > bugs).
>=20
> You mean tc-frer should inherit from the get-go the plethora of bugs
> from the unmaintained hsr driver? :)
>=20
> That would be good for hsr, which is in a pretty poor state, but the
> design of the 802.1CB spec isn't really in its favor sadly.
>=20
> > >
> > > You can see chapter "D.2 Example 2: Various stack positions" in IEEE =
802.1CB-2017,
> > > Protocol stack for relay system is like follows:
> > >
> > >              Stream Transfer Function
> > >                 |             |
> > >   				|    	Sequence generation
> > >                 |       	Sequence encode/decode
> > >   Stream identification		Active Stream identification
> > > 				|			  |
> > >   			    |		Internal LAN---- Relay system forwarding
> > > 				|						|		|
> > > 				MAC						MAC		MAC
> > >
> > > Use port actions to easily implement FRER tag add/delete, split, and
> > > recover functions.
> > >
> > > Current HSR/PRP driver can be used for port HSR/PRP set, and tc-frer
> > > Action to be used for stream RTAG/HSR/PRP set and recover.
> >=20
> > I am still reading the spec and trying to imagine how things would fit
> > together:
> >   - for which use cases tc-frer would be useful;
> >   - for which use cases the hsr netdevice would be useful;
> >   - would it make sense to have them in the same system?
>=20
> You could use FRER in networks where normally you'd use HSR (aka rings).
> In fact the 802.1CB demonstration I have, which uses the NXP tsntool
> program with the downstream genetlink tsn interface, does exactly that:
> https://github.com/vladimiroltean/tsn-scripts
>=20
> Basically FRER is IEEE's take on redundancy protocols and more like a
> generalization of HSR/PRP, the big changes are:
> - not limited to two (or any number of) ports
> - more than one type of stream/flow identification function: can look at
>   source/destination MAC, source/destination IP, VLAN, and most
>   importantly, there can be passive stream identification functions (don'=
t
>   modify the packet) and active stream identification functions (do
>   modify the packet).
>=20
> Please note that we've already started modeling IEEE 802.1CB stream
> identification functions as tc flower filters, since those map nicely on =
top.
> We use these for PSFP (former 802.1Qci) tc-police and tc-gate actions
> (yes, tc-police is single-bucket and color-unaware, that needs to be impr=
oved).
>=20
> Basically IEEE 802.1CB is a huge toolbox, the spec gives you the tools
> but it doesn't tell you how to use them, that's why the stream
> identification functions are so generic and decoupled from the
> redundancy protocol itself.
>=20
> In both HSR and PRP, sequence numbers are kept per source MAC address,
> that is absolutely baken into the standard.
>=20
> But think about this. When the sequence number is kept per source
> station, frames sent from node A to multiple destinations (nodes B and C)
> will be part of the same stream. So nodes B and C will see
> discontinuities in the sequence numbers when node A talks to them.
>=20
> The opposite is true as well. When sequence numbers are kept per
> destination MAC address, then frames sent from multiple talkers (nodes A
> and B) to the same destination (node C) will be interpreted as part of
> the same stream by the listener. So there will be jumps in sequence
> numbers seen by C when A and B are simultaneously transmitting to it.
>=20
> Which type of stream identification you need depends on the traffic you
> need to support, and the topology.
>=20
> So again, IEEE 802.1CB doesn't tell you what to do, but it gives you the
> tools. You can do source MAC based stream identification, and you can
> emulate HSR, or you can do something that encompasses both source node
> information as well as destination node information.
>=20
> It's one whole degree of freedom more flexible, plain and simple.
> And the topologies are not limited to:
> - the rings that HSR supports
> - the disjoint IP networks that PRP supports
> but are rather generic graphs.
>=20
> I fully expect there to be hardware out there already that can convert
> between the HSR/PRP frame format on one set of ports to 802.1CB frame
> format on another set of ports. Maybe that's something that some thought
> needs to be put into.

And Xiaoliang, can you PLEASE remove the following email addresses from
further submissions you make:
andre.guedes@linux.intel.com
vishal@chelsio.com
ivan.khoronzhuk@linaro.org
m-karicheri2@ti.com
Arvid.Brodin@xdin.com

You also copied some of them on all 6 submissions for the PSFP offload seri=
es.
It gets really annoying to get email bounces from these addresses.
I've removed them from this email thread. Thanks.=