On Wed, 18 Nov 2020 21:57:57 -0800 Saeed Mahameed wrote: > 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. Ack, the concern is about the vdpa, not SF. So not really this patch set.
