On Sun, 2020-09-06 at 20:21 +0200, Horatiu Vultur wrote:
The 09/04/2020 15:44, Stephen Hemminger wrote:
quoted
On Fri, 4 Sep 2020 09:15:20 +0000
Henrik Bjoernlund [off-list ref] wrote:
quoted
Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14.
[snip]
quoted
quoted
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 <redacted>
Hi Stephen,
quoted
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.
quoted
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