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

From: Vinicius Costa Gomes
Date: Fri Oct 01 2021 - 13:27:17 EST


Xiaoliang Yang <xiaoliang.yang_1@xxxxxxx> writes:

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