> >This API gives user space SDKs a trivial way of implementing all > >switching, routing, filtering, QoS offloads etc. > >An argument can be made that given somewhat mixed switchdev experience > > Can you elaborabe a bit more what you mean by "mixed switchdev > experience" please? I don't want to put words in Jakubs mouth but, in my opinion, switchdev has been great for SoHo switches. We have over 100 supported, mostly implemented by the community, but some vendors also supporting their own hardware. We have two enterprise switch families supported, each by its own vendor. And we have one TOR switch family supported by the vendor. So i would say switchdev has worked out great for SoHo, but kernel bypass is still the norm for most things bigger than SoHo. Why? My guess is, the products with a SoHo switch is not actually a switch. It is a wifi box, with a switch. It is a cable modem, with a switch. It is an inflight entertainment system, with a switch, etc. It is much easier to build such multi-purpose systems when everything is nicely integrated into the kernel, you don't have to fight with multiple vendors supplying SDKs which only work on a disjoint set of kernels, etc. For bigger, single purpose devices, it is just a switch, there is less inconvenience of using just one vendor SDK, on top of the vendor proscribed kernel. Andrew
