On Thu, Dec 17, 2020 at 10:48:48AM -0800, Alexander Duyck wrote: > Just to clarify I am not with Intel, nor do I plan to work on any > Intel drivers related to this. Sure > I disagree here. In my mind a design where two interfaces, which both > exist in the kernel, have to go to hardware in order to communicate is > very limiting. The main thing I am wanting to see is the option of > being able to pass traffic directly between the switchdev and the SF > without the need to touch the hardware. I view the SW bypass path you are talking about similarly to GSO/etc. It should be accessed by the HW driver as an optional service provided by the core netdev, not implemented as some wrapper netdev around a HW implementation. If you feel strongly it is needed then there is nothing standing in the way to implement it in the switchdev auxdevice model. It is simple enough, the HW driver's tx path would somehow detect east/west and queue it differently, and the rx path would somehow be able to mux in skbs from a SW queue. Not seeing any blockers here. > > model. I would recommend creating a simple RDMA raw ethernet queue > > driver over the aux device for something like this :) > > You lost me here, I'm not seeing how RDMA and macvlan are connected. RDMA is the standard uAPI to get a userspace HW DMA queue for ethernet packets. > > > Essentially what I am getting at is that the setup in the container > > > should be vendor agnostic. The interface exposed shouldn't be specific > > > to any one vendor. So if I want to fire up a container or Mellanox, > > > Broadcom, or some other vendor it shouldn't matter or be visible to > > > the user. They should just see a vendor agnostic subfunction > > > netdevice. > > > > Agree. The agnostic container user interface here is 'struct > > net_device'. > > I disagree here. The fact is a mellanox netdev, versus a broadcom > netdev, versus an intel netdev all have a very different look at feel > as the netdev is essentially just the base device you are building > around. Then fix the lack of standardization of netdev implementations! Adding more abstraction layers isn't going to fix that fundamental problem. Frankly it seems a bit absurd to complain that the very basic element of the common kernel uAPI - struct net_device - is so horribly fragmented and vendor polluted that we can't rely on it as a stable interface for containers. Even if that is true, I don't belive for a second that adding a different HW abstraction layer is going to somehow undo the mistakes of the last 20 years. > Again, the hot-swap isn't necessarily what I am talking about. I am > talking about setting up a config for a set of containers in a > datacenter. What I don't want to do is have to have one set of configs > for an mlx5 SF, another for a broadcom SF, and yet another set for any > other vendors out there. I would much rather have all of that dealt > with within the namespace that is handling the switchdev setup. If there is real problems here then I very much encourage you to start an effort to push all the vendors to implement a consistent user experience for the HW netdevs. I don't know what your issues are, but it sounds like it would be a very interesting conference presentation. But it has nothing to do with this series. Jason
