From: "Asbjørn Sloth Tønnesen" <ast@fiberby.net>
To: Stephen Hemminger <stephen@networkplumber.org>,
Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: andrew@lunn.ch, jakub.kicinski@netronome.com,
nikolay@cumulusnetworks.com, netdev@vger.kernel.org,
roopa@cumulusnetworks.com, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, vivien.didelot@gmail.com,
UNGLinuxDriver@microchip.com, anirudh.venkataramanan@intel.com,
jiri@mellanox.com, jeffrey.t.kirsher@intel.com,
dsahern@gmail.com, olteanv@gmail.com, davem@davemloft.net,
Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: [Bridge] [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)
Date: Thu, 9 Jan 2020 17:41:33 +0000 [thread overview]
Message-ID: <da02006c-dc9d-ce1a-861e-4fc1c1dc2830@fiberby.net> (raw)
In-Reply-To: <20200109081907.06281c0f@hermes.lan>
Hi Horatiu and Stephen,
Horatiu, thanks for giving this a try. I am looking forward to maybe someday
be able to run ERPS on white box switches.
On 1/9/20 4:19 PM, Stephen Hemminger wrote:
> Can this be implemented in userspace?
>
> 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.
Another case is VRRP, ERPS (ITU-T G.8032), VRRP group.
My use-case might not be common, but I have machines with about 10k net_dev (QinQ),
I would like to be able to do VRRP group on the outer VLANs, which are only a few
hundred instances without excessive context switching. I would then keep the the
normal keep-alive state machine in kernel, basically a BPF-based timed periodic
packet emitter facility and a XDP recieve hook. So only setup and event handling
has to context switched to user-space.
Unfortunately I haven't had time to explore this yet, but I think such an approach
could solve a few of the reasons that scalable bridge/ring/ha protocols have to wait
20 years before being implemented in Linux.
--
Best regards
Asbjørn Sloth Tønnesen
Network Engineer
Fiberby ApS - AS42541
WARNING: multiple messages have this Message-ID (diff)
From: "Asbjørn Sloth Tønnesen" <ast@fiberby.net>
To: Stephen Hemminger <stephen@networkplumber.org>,
Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: andrew@lunn.ch, jakub.kicinski@netronome.com,
davem@davemloft.net, nikolay@cumulusnetworks.com,
netdev@vger.kernel.org, roopa@cumulusnetworks.com,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
UNGLinuxDriver@microchip.com,
Jesper Dangaard Brouer <brouer@redhat.com>,
anirudh.venkataramanan@intel.com, jiri@mellanox.com,
jeffrey.t.kirsher@intel.com, dsahern@gmail.com,
olteanv@gmail.com, vivien.didelot@gmail.com
Subject: Re: [Bridge] [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)
Date: Thu, 9 Jan 2020 17:41:33 +0000 [thread overview]
Message-ID: <da02006c-dc9d-ce1a-861e-4fc1c1dc2830@fiberby.net> (raw)
In-Reply-To: <20200109081907.06281c0f@hermes.lan>
Hi Horatiu and Stephen,
Horatiu, thanks for giving this a try. I am looking forward to maybe someday
be able to run ERPS on white box switches.
On 1/9/20 4:19 PM, Stephen Hemminger wrote:
> Can this be implemented in userspace?
>
> 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.
Another case is VRRP, ERPS (ITU-T G.8032), VRRP group.
My use-case might not be common, but I have machines with about 10k net_dev (QinQ),
I would like to be able to do VRRP group on the outer VLANs, which are only a few
hundred instances without excessive context switching. I would then keep the the
normal keep-alive state machine in kernel, basically a BPF-based timed periodic
packet emitter facility and a XDP recieve hook. So only setup and event handling
has to context switched to user-space.
Unfortunately I haven't had time to explore this yet, but I think such an approach
could solve a few of the reasons that scalable bridge/ring/ha protocols have to wait
20 years before being implemented in Linux.
--
Best regards
Asbjørn Sloth Tønnesen
Network Engineer
Fiberby ApS - AS42541
next prev parent reply other threads:[~2020-01-09 17:50 UTC|newest]
Thread overview: 42+ 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 ` [Bridge] " 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 ` [Bridge] " 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 ` [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 15:06 ` [Bridge] " Horatiu Vultur
2020-01-10 14:27 ` kbuild test robot
2020-01-10 14:52 ` kbuild test robot
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 16:19 ` [Bridge] " Stephen Hemminger
2020-01-09 17:41 ` Asbjørn Sloth Tønnesen [this message]
2020-01-09 17:41 ` Asbjørn Sloth Tønnesen
2020-01-10 9:02 ` Horatiu Vultur
2020-01-10 9:02 ` [Bridge] " Horatiu Vultur
2020-01-10 15:36 ` Stephen Hemminger
2020-01-10 15:36 ` [Bridge] " Stephen Hemminger
2020-01-10 14:13 ` Nikolay Aleksandrov
2020-01-10 14:13 ` [Bridge] " Nikolay Aleksandrov
2020-01-10 15:38 ` Nikolay Aleksandrov
2020-01-10 15:38 ` [Bridge] " Nikolay Aleksandrov
2020-01-10 16:04 ` Horatiu Vultur
2020-01-10 16:04 ` [Bridge] " Horatiu Vultur
2020-01-10 16:21 ` Vladimir Oltean
2020-01-10 16:21 ` [Bridge] " Vladimir Oltean
2020-01-10 16:48 ` Andrew Lunn
2020-01-10 16:48 ` [Bridge] " Andrew Lunn
2020-01-10 17:25 ` Horatiu Vultur
2020-01-10 17:25 ` [Bridge] " Horatiu Vultur
2020-01-10 17:56 ` Andrew Lunn
2020-01-10 17:56 ` [Bridge] " Andrew Lunn
2020-01-10 20:12 ` Horatiu Vultur
2020-01-10 20:12 ` [Bridge] " Horatiu Vultur
2020-01-10 20:33 ` Andrew Lunn
2020-01-10 20:33 ` [Bridge] " Andrew Lunn
2020-01-10 19:27 ` David Miller
2020-01-10 19:27 ` [Bridge] " David Miller
2020-01-10 20:03 ` nikolay
2020-01-10 20:03 ` [Bridge] " nikolay
2020-01-10 20:24 ` Horatiu Vultur
2020-01-10 20:24 ` [Bridge] " 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=da02006c-dc9d-ce1a-861e-4fc1c1dc2830@fiberby.net \
--to=ast@fiberby.net \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=anirudh.venkataramanan@intel.com \
--cc=bridge@lists.linux-foundation.org \
--cc=brouer@redhat.com \
--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=stephen@networkplumber.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.