On Wed, 2020-11-18 at 18:23 -0800, Jakub Kicinski wrote: > On Tue, 17 Nov 2020 18:50:57 +0000 Parav Pandit wrote: > > At this point vdpa tool of [1] can create one or more vdpa net > > devices on this subfunction device in below sequence. > > > > $ vdpa parentdev list > > auxiliary/mlx5_core.sf.4 > > supported_classes > > net > > > > $ vdpa dev add parentdev auxiliary/mlx5_core.sf.4 type net name > > foo0 > > > > $ vdpa dev show foo0 > > foo0: parentdev auxiliary/mlx5_core.sf.4 type network parentdev > > vdpasim vendor_id 0 max_vqs 2 max_vq_size 256 > > > > > I'm asking how the vdpa API fits in with this, and you're showing > > > me the two > > > devlink commands we already talked about in the past. > > Oh ok, sorry, my bad. I understood your question now about relation > > of vdpa commands with this. > > Please look at the above example sequence that covers the vdpa > > example also. > > > > [1] > > https://lore.kernel.org/netdev/20201112064005.349268-1-parav@xxxxxxxxxx/ > > I think the biggest missing piece in my understanding is what's the > technical difference between an SF and a VDPA device. > Same difference as between a VF and netdev. SF == VF, so a full HW function. VDPA/RDMA/netdev/SCSI/nvme/etc.. are just interfaces (ULPs) sharing the same functions as always been, nothing new about this. Today on a VF we load a RDMA/VDPA/netdev interfaces SF will do exactly the same and the ULPs will simply load, and we don't need to modify them. > Isn't a VDPA device an SF with a particular descriptor format for the > queues? No :/, I hope the above answer clarifies things a bit. SF is a device function that provides all kinds of queues.
