On Fri, 10 Jan 2020 10:02:06 +0100 Horatiu Vultur <horatiu.vultur@xxxxxxxxxxxxx> 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.
