Tue, Mar 07, 2023 at 06:20:03PM CET, m...@redhat.com wrote: >On Tue, Mar 07, 2023 at 08:21:54AM +0100, Jiri Pirko wrote: >> Mon, Mar 06, 2023 at 11:54:45PM CET, m...@redhat.com wrote: >> >On Mon, Mar 06, 2023 at 01:29:30PM +0100, Jiri Pirko wrote: >> >> Thu, Mar 02, 2023 at 02:04:48PM CET, m...@redhat.com wrote: >> >> >> >> [...] >> >> >> >> > >> >> >TODO (maybe?) - probably ok to defer until this part is upstream: >> >> > >> >> > Add "all members" member id. >> >> > >> >> > Add commands for MSI, feature discovery. >> >> > >> >> > Add commands for transport vq. >> >> > >> >> > >> >> >My intent is to try and support both SR-IOV and SIOV >> >> >usecases with the same structure and maybe even the same >> >> >VQ. >> >> >> >> Sorry to be late to the party, I'm trying to catch up. Is it common to >> >> have cover letter for features this brief? I mean, from the cover >> >> letter, I'm totally unable to understand what you are introducing here. >> >> >> >> Could you elaborate about what you are aiming to achive with this? >> >> Could you shed some usecases perhaps? >> >> >> >> I have to be missing something obvious, but I don't get why any notion >> >> of SR-IOV could be beneficial for virtio. >> >> >> > >> >Good point, I'll add a bit of motivation. >> > >> >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.
Yep, I talked to Parav, makes much more sense now for me as I now understand the motivation. I was not able to reach there just by reading the patchset :/ > > > > >> >> >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. Cool. > >> > >> > >> > >> > >> >> > >> >> >For example, it might make sense to split creating/destroying >> >> >SIOV devices from the transport passing data from the guest - the >> >> >driver would then not negotiate VIRTIO_F_SR_IOV (which >> >> >then means auto-provisioning). >> >> > >> >> >This is out of RFC, since we have two commands which are useful >> >> >to discover supported group types (ATM can be none or SR-IOV). >> >> > >> >> > >> >> >Michael S. Tsirkin (10): >> >> > virtio: document forward compatibility guarantees >> >> > admin: introduce device group and related concepts >> >> > admin: introduce group administration commands >> >> > admin: introduce virtio admin virtqueues >> >> > pci: add admin vq registers to virtio over pci >> >> > mmio: document ADMIN_VQ as reserved >> >> > ccw: document ADMIN_VQ as reserved >> >> > admin: command list discovery >> >> > admin: conformance clauses >> >> > ccw: document more reserved features >> >> > >> >> > admin.tex | 540 +++++++++++++++++++++++++++++++++++++++++++++++ >> >> > content.tex | 112 +++++++++- >> >> > introduction.tex | 3 + >> >> > 3 files changed, 653 insertions(+), 2 deletions(-) >> >> > create mode 100644 admin.tex >> >> > >> >> >-- >> >> >MST >> >> > >> >> > >> >> >This publicly archived list offers a means to provide input to the >> >> >OASIS Virtual I/O Device (VIRTIO) TC. >> >> > >> >> >In order to verify user consent to the Feedback License terms and >> >> >to minimize spam in the list archive, subscription is required >> >> >before posting. >> >> > >> >> >Subscribe: virtio-comment-subscr...@lists.oasis-open.org >> >> >Unsubscribe: virtio-comment-unsubscr...@lists.oasis-open.org >> >> >List help: virtio-comment-h...@lists.oasis-open.org >> >> >List archive: https://lists.oasis-open.org/archives/virtio-comment/ >> >> >Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf >> >> >List Guidelines: >> >> >https://www.oasis-open.org/policies-guidelines/mailing-lists >> >> >Committee: https://www.oasis-open.org/committees/virtio/ >> >> >Join OASIS: https://www.oasis-open.org/join/ >> >> > >> >> >> >> This publicly archived list offers a means to provide input to the >> >> OASIS Virtual I/O Device (VIRTIO) TC. >> >> >> >> In order to verify user consent to the Feedback License terms and >> >> to minimize spam in the list archive, subscription is required >> >> before posting. >> >> >> >> Subscribe: virtio-comment-subscr...@lists.oasis-open.org >> >> Unsubscribe: virtio-comment-unsubscr...@lists.oasis-open.org >> >> List help: virtio-comment-h...@lists.oasis-open.org >> >> List archive: https://lists.oasis-open.org/archives/virtio-comment/ >> >> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf >> >> List Guidelines: >> >> https://www.oasis-open.org/policies-guidelines/mailing-lists >> >> Committee: https://www.oasis-open.org/committees/virtio/ >> >> Join OASIS: https://www.oasis-open.org/join/ >> > > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org