[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] [PATCH v10 00/10] Introduce device group and device management
On Wed, Mar 8, 2023 at 3:31âAM Parav Pandit <parav@nvidia.com> wrote: > > > > From: Michael S. Tsirkin <mst@redhat.com> > > Sent: Tuesday, March 7, 2023 12:20 PM > > [..] > > > >For SR-IOV, it is not unusual for PFs to excercise control over VFs. > > > > > > I understand the concepts of SR-IOV. Yet I fail to see the need of > > > such concept in virtio world. SR-IOV is very specific solution for PCI > > > functions instantiation, and I believe that it is already considered > > > quite limiting in many aspects. Does not make sense to me to introduce > > > it for virtio. But again, I may be missing something crucial, I just > > > would like to see the motivation, needs, usecases for this crystal > > > clear, which is opposite to the current cover letter I'm afraid :/ > > > > First people are asking for it because it's out there, however limiting it is. In > > fact Nvidia is - why don't you talk to Parav here and tell him that SR-IOV is > > legacy and there's no need to support. > > > Jiri and I discussed offline today. > SR-IOV is widely used today and in the coming future up to thousands of devices. > Many vendors are building it or already built. > > SIOV as it stands today is still being crafted at various levels iommu, os, device, pci and more. > Not there yet fully. > > Jiri and I built the Linux kernel interfaces for SFs which are equivalent to SIOVs that overcome some of the SR-IOV limitations. > And Jiri's suggestion was to leverage some of the vision and practice from there. > > In other words, can AQ command be useful tomorrow for doing SIOV device add/remove, and provisioning from non-owning PF? > The way AQ is crafted today is not there yet, but in the future, it can be extended. There's already a proposal to use the queue as a transport. Any device that can't use a transport specific configuration or provisioning can benefit from that. SIOV is only one of the users for that. > > > > > > > > >There is interest in the community to include an interface to allow > > > >this in the virtio spec, when the PF is a virtio device. This is > > > >what this patch does. > > > > > > Yeah, but why? As I asked before, what are the usecases? The fact > > > there is interest in the community does not mean it makes sense to > > > have it :) > > > > > > > If people want to build such hardware it will need some interface. > > Far better to have it standard. > > > > > > But generally e.g. intel already said they will reuse this same structure with a > > different group type for SIOV support. > > I'll mention this in the cover letter. > > > > We have the following already identified use cases of a device agnostic VQ. > > 1. SR-IOV VF device provisioning at virtio layer (features and config) > 2. SR IOV (SR-PCIM interface of the PCI spec) for VF provisioning, for example, MSI-X vectors > The virtio layer device provisioning is transport independent. I don't see anything that is PCI specific there. Even the MSI-X could be reused by other transport. > 3. SR-IOV VF Live migration I think we don't want a partial solution for live migration that only works for PCI VF devices and L1. Instead, there needs to be a general device facility section and the admin virtqueue could be one of the interfaces for the driver to use the facility. > 4. Above #1 to #3 for SIOV devices instead of SRIOV devices If we make the above as a general facility, it would not be hard to re-use them for transport virtqueue or SIOV. Thanks > > 5. cmd q interface for PF/VF/SF/SIOV to transport their own features, config command over queue interface without any parent device > > #1 to #3 are well described in past. So, It is worth covering them in the cover letter and things will be clear for new eyes. > #4 is broad use case and like #1 to #3 that will eventually happen. > #5 likely needs more discussion, we can differ to a later point because AQ needs to progress in spec 1.3. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]