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

[<Henrik.Bjoernlund@microchip.com>]

Hi Nik,

Thanks a lot for reviewing.

-----Original Message-----
From: Nikolay Aleksandrov <nikolay@nvidia.com> 
Sent: 7. september 2020 15:56
To: stephen@networkplumber.org; Horatiu Vultur - M31836 <Horatiu.Vultur@microchip.com>
Cc: bridge@lists.linux-foundation.org; Henrik Bjoernlund - M31679 <Henrik.Bjoernlund@microchip.com>; davem@davemloft.net; linux-kernel@vger.kernel.org; jiri@mellanox.com; netdev@vger.kernel.org; Roopa Prabhu <roopa@nvidia.com>; idosch@mellanox.com; kuba@kernel.org; UNGLinuxDriver <UNGLinuxDriver@microchip.com>
Subject: Re: [PATCH RFC 0/7] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

>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 ?
>

Yes.

The HW will offload the periodic sending of CCM frames, and the reception.

If CCM frames are not received as expected, it will raise an interrupt.

This means that all the functionality provided in this series will be offloaded to HW.

The offloading is very important on our HW where we have a small CPU, serving many ports, with a high frequency of CFM frames.

The HW also support Link-Trace and Loop-back, which we may come back to later.

>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