RE: [EXT] Re: [RFC, net-next] net: qos: introduce a frer action to implement 802.1CB

Xiaoliang Yang [off-list ref] writes:

Hi Vinicius,

On Sep 29, 2021 at 6:35:59 +0000, Vinicius Costa Gomes wrote:

quoted

quoted

This patch introduce a frer action to implement frame replication and
elimination for reliability, which is defined in IEEE P802.1CB.

An action seems, to me, a bit too limiting/fine grained for a frame replication
and elimination feature.

At least I want to hear the reasons that the current hsr/prp support cannot be
extended to support one more tag format/protocol.

And the current name for the spec is IEEE 802.1CB-2017.

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.

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.

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.

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. 

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).

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.

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?
  

Thanks,
Xiaoliang

Cheers,
-- 
Vinicius