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.
next prev parent reply other threads:[~2020-01-10 15:36 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-09 15:06 [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP) Horatiu Vultur
2020-01-09 15:06 ` [RFC net-next Patch 1/3] net: bridge: mrp: Add support for Media Redundancy Protocol Horatiu Vultur
2020-01-09 15:06 ` [RFC net-next Patch 2/3] net: bridge: mrp: Integrate MRP into the bridge Horatiu Vultur
2020-01-09 15:06 ` [RFC net-next Patch 3/3] net: bridge: mrp: Add netlink support to configure MRP Horatiu Vultur
2020-01-09 16:19 ` [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP) Stephen Hemminger
2020-01-09 17:41 ` [Bridge] " Asbjørn Sloth Tønnesen
2020-01-10 9:02 ` Horatiu Vultur
2020-01-10 15:36 ` Stephen Hemminger [this message]
2020-01-10 14:13 ` Nikolay Aleksandrov
2020-01-10 15:38 ` Nikolay Aleksandrov
2020-01-10 16:04 ` Horatiu Vultur
2020-01-10 16:21 ` Vladimir Oltean
2020-01-10 16:48 ` Andrew Lunn
2020-01-10 17:25 ` Horatiu Vultur
2020-01-10 17:56 ` Andrew Lunn
2020-01-10 20:12 ` Horatiu Vultur
2020-01-10 20:33 ` Andrew Lunn
2020-01-10 19:27 ` David Miller
2020-01-10 20:03 ` nikolay
2020-01-10 20:24 ` Horatiu Vultur
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200110073609.0eddf6e3@hermes.lan \
--to=stephen@networkplumber.org \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=anirudh.venkataramanan@intel.com \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=horatiu.vultur@microchip.com \
--cc=jakub.kicinski@netronome.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jiri@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=olteanv@gmail.com \
--cc=roopa@cumulusnetworks.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).