Re: [RFC net-next v3 00/10] net: bridge: mrp: Add support for Media Redundancy Protocol (MRP)

[Vinicius Costa Gomes <vinicius.gomes@intel.com>]

Hi,

"Allan W. Nielsen" <allan.nielsen@microchip.com> writes:

> On 24.01.2020 17:18, Horatiu Vultur wrote:
>>Media Redundancy Protocol is a data network protocol standardized by
>>International Electrotechnical Commission as IEC 62439-2. It allows rings of
>>Ethernet switches to overcome any single failure with recovery time faster than
>>STP. It is primarily used in Industrial Ethernet applications.
>>
>>Based on the previous RFC[1][2], the MRP state machine and all the
>>timers were moved to userspace. A generic netlink interface is added to
>>allow configuring the HW, and logic added to to implement the MRP
>>specific forwarding rules.
>>
>>The userspace application that is using the new netlink can be found here[3].
>>
>>The current implementation both in kernel and userspace supports only 2 roles:
>>
>>  MRM - this one is responsible to send MRP_Test and MRP_Topo frames on both
>>  ring ports. It needs to process MRP_Test to know if the ring is open or
>>  closed. This operation is desired to be offloaded to the HW because it
>>  requires to generate and process up to 4000 frames per second. Whenever it
>>  detects that the ring open it sends MRP_Topo frames to notify all MRC about
>>  changes in the topology. MRM needs also to process MRP_LinkChange frames,
>>  these frames are generated by the MRC. When the ring is open the the state
>>  of both ports is to forward frames and when the ring is closed then the
>>  secondary port is blocked.
>>
>>  MRC - this one is responsible to forward MRP frames between the ring ports.
>>  In case one of the ring ports gets a link down or up, then MRC will generate
>>  a MRP_LinkChange frames. This node should also process MRP_Topo frames and to
>>  clear its FDB when it receives this frame.
>>
>> Userspace
>>               Deamon +----------+ Client
>>                +
>>                |
>> +--------------|-----------------------------------------+
>>  Kernel        |
>>                + Netlink
>>
>>                |                              + Interrupt
>>                |                              |
>> +--------------|------------------------------|----------+
>>  HW            | Switchdev                    |
>>                +                              |
>>
>>The user interacts using the client (called 'mrp'), the client talks to the
>>deamon (called 'mrp_server'), which talks with the kernel using netlink. The
>>kernel will try to offload the requests to the HW via switchdev API. For this a
>>new generic netlink interface was added to the bridge.
>>
>>If the kernel cannot offload MRP to HW (maybe it does not have a switchdev
>>driver, or it is just not supported), then all the netlink calls will return
>>-EOPNOTSUPP. In this case the user-space deamon fallback to SW only
>>implementation.
> Horatiu and I have spend a bit of time discussing what you be best here.
> An alternative to this would be to do the SW fallback in the kernel,
> instead of user-land. This would mean that the user application does not
> need to know if the function is offloaded (or partly offloaded) to HW.
>
> We went with this approch to make the kernel part as simple as possible.
> The alternative would still be much simpler than the first version
> posted - but it would require a bit more.
>
> Both options has pros and cons, and we looking forward to the
> community's view on this.

I have one idea and one question.

The idea is:

'net/hsr' already has a software implementation of the HSR replication
tag (and some of the handling necessary). So what came to mind is to
add the necessary switchdev functions to the master HSR device. If
that's done, then it sounds that the rest will mostly work.

For the user the flow would be something like:

 - User takes two (or more interfaces) and set them as slaves of the HSR
   master device, say 'hsr0';

 - 'hsr0' implements some of the switchdev functionality so we can use
   the MRP userspace components on it;

Does it look like something that could work?

The question that I have is: what's the relation of IEC 62439-2 to IEEE
802.1CB? 


Cheers,
--
Vinicius