Re: [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>,
	"horatiu.vultur@microchip.com" <horatiu.vultur@microchip.com>
Cc: "bridge@lists.linux-foundation.org" 
	<bridge@lists.linux-foundation.org>,
	"henrik.bjoernlund@microchip.com"
	<henrik.bjoernlund@microchip.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jiri@mellanox.com" <jiri@mellanox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Roopa Prabhu <roopa@nvidia.com>,
	"idosch@mellanox.com" <idosch@mellanox.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>
Subject: Re: [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)
Date: Mon, 7 Sep 2020 13:56:20 +0000	[thread overview]
Message-ID: <b36a32dbf3b4b315fc4cbfdf06084b75a7c58729.camel@nvidia.com> (raw)
In-Reply-To: <20200906182129.274fimjyo7l52puj@soft-dev3.localdomain>

On Sun, 2020-09-06 at 20:21 +0200, Horatiu Vultur wrote:
> The 09/04/2020 15:44, Stephen Hemminger wrote:
> > On Fri, 4 Sep 2020 09:15:20 +0000
> > Henrik Bjoernlund <henrik.bjoernlund@microchip.com> wrote:
> > 
> > > Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14.
> > > 
> > > 
[snip]
> > > Currently this 'cfm' and 'cfm_server' programs are standalone placed in a
> > > cfm repository https://github.com/microchip-ung/cfm but it is considered
> > > to integrate this into 'iproute2'.
> > > 
> > > Reviewed-by: Horatiu Vultur  <horatiu.vultur@microchip.com>
> > > Signed-off-by: Henrik Bjoernlund  <henrik.bjoernlund@microchip.com>
> 
> Hi Stephen,
> 
> > Could this be done in userspace? It is a control plane protocol.
> > Could it be done by using eBPF?
> 
> I might be able to answer this. We have not considered this approach of
> using eBPF. Because we want actually to push this in HW extending
> switchdev API. I know that this series doesn't cover the switchdev part
> but we posted like this because we wanted to get some feedback from
> community. We had a similar approach for MRP, where we extended the
> bridge and switchdev API, so we tought that is the way to go forward.
> 
> Regarding eBPF, I can't say that it would work or not because I lack
> knowledge in this.
> 
> > Adding more code in bridge impacts a large number of users of Linux distros.
> > It creates bloat and potential security vulnerabilities.

Hi,
I also had the same initial thought - this really doesn't seem to affect the
bridge in any way, it's only collecting and transmitting information. I get
that you'd like to use the bridge as a passthrough device to switchdev to
program your hw, could you share what would be offloaded more specifically ?

All you do - snooping and blocking these packets can easily be done from user-
space with the help of ebtables, but since we need to have a software
implementation/fallback of anything being offloaded via switchdev we might need
this after all, I'd just prefer to push as much as possible to user-space.

I plan to review the individual patches tomorrow.

Thanks,
 Nik