On Fri, Dec 18, 2020 at 12:18 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Fri, Dec 18, 2020 at 11:22:12AM -0800, Alexander Duyck wrote: > > > Also as far as the patch count complaints I have seen in a few threads > > I would be fine with splitting things up so that the devlink and aux > > device creation get handled in one set, and then we work out the > > details of mlx5 attaching to the devices and spawning of the SF > > netdevs in another since that seems to be where the debate is. > > It doesn't work like that. The aux device creates a mlx5_core and > every mlx5_core can run mlx5_en. The aux device is still just a device isn't it? Until you register a driver that latches on to "MLX5_SF_DEV_ID_NAME" the device is there and it should function like an unbound/idle VF. > This really isn't the series to raise this feature request. Adding an > optional short cut path to VF/SF is something that can be done later > if up to date benchmarks show it has value. There is no blocker in > this model to doing that. That is the point of contention that we probably won't solve. I feel like if we are going to put out something that is an alternative to the macvlan and SR-IOV approaches it should address the issues resolved in both. Right now this just throws up yet another virtualization solution that ends up reintroducing many of the existing problems we already had with SR-IOV, and possibly exacerbating them by allowing for an even greater number of subfunctions. Anyway I have made my opinion known, and I am not in the position to block the patches since I am not the maintainer.
