On Wed, 2020-11-18 at 21:35 -0700, David Ahern wrote: > On 11/18/20 7:14 PM, Jakub Kicinski wrote: > > On Tue, 17 Nov 2020 14:49:54 -0400 Jason Gunthorpe wrote: > > > On Tue, Nov 17, 2020 at 09:11:20AM -0800, Jakub Kicinski wrote: > > > > > > > > Just to refresh all our memory, we discussed and settled on > > > > > the flow > > > > > in [2]; RFC [1] followed this discussion. > > > > > > > > > > vdpa tool of [3] can add one or more vdpa device(s) on top of > > > > > already > > > > > spawned PF, VF, SF device. > > > > > > > > Nack for the networking part of that. It'd basically be VMDq. > > > > > > What are you NAK'ing? > > > > Spawning multiple netdevs from one device by slicing up its queues. > > Why do you object to that? Slicing up h/w resources for virtual what > ever has been common practice for a long time. > > We are not slicing up any queues, from our HW and FW perspective SF == VF literally, a full blown HW slice (Function), with isolated control and data plane of its own, this is very different from VMDq and more generic and secure. an SF device is exactly like a VF, doesn't steal or share any HW resources or control/data path with others. SF is basically SRIOV done right. this series has nothing to do with netdev, if you look at the list of files Parav is touching, there is 0 change in our netdev stack :) .. all Parav is doing is adding the API to create/destroy SFs and represents the low level SF function to devlink as a device, just like a VF.
