Re: [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)

From: Stephen Hemminger <stephen@networkplumber.org>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
	<bridge@lists.linux-foundation.org>, <davem@davemloft.net>,
	<roopa@cumulusnetworks.com>, <nikolay@cumulusnetworks.com>,
	<jakub.kicinski@netronome.com>, <vivien.didelot@gmail.com>,
	<andrew@lunn.ch>, <jeffrey.t.kirsher@intel.com>,
	<olteanv@gmail.com>, <anirudh.venkataramanan@intel.com>,
	<dsahern@gmail.com>, <jiri@mellanox.com>,
	<UNGLinuxDriver@microchip.com>
Subject: Re: [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)
Date: Fri, 10 Jan 2020 07:36:09 -0800	[thread overview]
Message-ID: <20200110073609.0eddf6e3@hermes.lan> (raw)
In-Reply-To: <20200110090206.gihfd3coeilkyi23@soft-dev3.microsemi.net>

On Fri, 10 Jan 2020 10:02:06 +0100
Horatiu Vultur <horatiu.vultur@microchip.com> wrote:

> > 
> > Can this be implemented in userspace?  
> 
> The reason for putting this in kernal space is to HW offload this in
> switchdev/dsa driver. The switches which typically supports this are
> small and don't have a lot of CPU power and the bandwidth between the
> CPU and switch core is typically limited(at least this is the case with
> the switches that we are working). Therefor we need to use HW offload
> components which can inject the frames at the needed frequency and other
> components which can terminate the expected frames and just raise and
> interrupt if the test frames are not received as expected(and a few
> other HW features).
> 
> To put this in user-space we see two options:
> 1. We need to define a netlink interface which allows a user-space
> control application to ask the kernel to ask the switchdev driver to
> setup the frame-injector or frame-terminator. In theory this would be
> possible, and we have considered it, but we think that this interface
> will be too specific for our HW and will need to be changed every time
> we want to add support for a new SoC. By focusing the user-space
> interfaces on the protocol requirement, we feel more confident that we
> have an interface which we can continue to be backwards compatible with,
> and also support future/other chips with what ever facilities (if any)
> they have to HW offload.
> 
> 2. Do a UIO driver and keep protocol and driver in user-space. We do not
> really like this approach for many reasons: it pretty much prevents us from
> collaborating with the community to solve this and it will be really hard
> to have the switchdev driver controlling part of the chip and a
> user-space driver controlling other parts.
> 
> > 
> > Putting STP in the kernel was a mistake (even original author says so).
> > Adding more control protocols in kernel is a security and stability risk.  

The principal in networking is to separate control and data plane.
This is widely adopted in many areas: OVS, routing, etc.

There is an existing devlink interface for device control, it would
make sense to extend it to allow for more control of frame inject etc.