From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 88DE5C64EC4 for ; Fri, 10 Mar 2023 08:32:33 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id DEFD52AD4B for ; Fri, 10 Mar 2023 08:32:32 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id C66CD98671E for ; Fri, 10 Mar 2023 08:32:32 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id B5ECC986717; Fri, 10 Mar 2023 08:32:32 +0000 (UTC) Mailing-List: contact virtio-comment-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id A1454986718; Fri, 10 Mar 2023 08:32:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-IronPort-AV: E=McAfee;i="6500,9779,10644"; a="316332373" X-IronPort-AV: E=Sophos;i="5.98,249,1673942400"; d="scan'208";a="316332373" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10644"; a="710203908" X-IronPort-AV: E=Sophos;i="5.98,249,1673942400"; d="scan'208";a="710203908" Message-ID: Date: Fri, 10 Mar 2023 16:32:15 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.8.0 Content-Language: en-US To: Parav Pandit , "Michael S. Tsirkin" , Jiri Pirko Cc: "virtio-comment@lists.oasis-open.org" , "virtio-dev@lists.oasis-open.org" , "jasowang@redhat.com" , "cohuck@redhat.com" , "sgarzare@redhat.com" , "stefanha@redhat.com" , "nrupal.jani@intel.com" , "Piotr.Uminski@intel.com" , "hang.yuan@intel.com" , "virtio@lists.oasis-open.org" , "pasic@linux.ibm.com" , Shahaf Shuler , Max Gurtovoy References: <20230306175020-mutt-send-email-mst@kernel.org> <20230307121529-mutt-send-email-mst@kernel.org> From: "Zhu, Lingshan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [virtio-comment] [PATCH v10 00/10] Introduce device group and device management On 3/8/2023 3:31 AM, Parav Pandit wrote: >> From: Michael S. Tsirkin >> 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. I have submitted a series implementing "transport vq" which work for ADIs like SIOV devices, MST required a merge with admin q, so we are here. >>>> 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 > > 3. SR-IOV VF Live migration > 4. Above #1 to #3 for SIOV devices instead of SRIOV devices > > 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. > > 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-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 84BE4C6FD19 for ; Fri, 10 Mar 2023 08:32:41 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id CCB6933576 for ; Fri, 10 Mar 2023 08:32:40 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id C8724986722 for ; Fri, 10 Mar 2023 08:32:40 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id BA871986717; Fri, 10 Mar 2023 08:32:40 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id A1454986718; Fri, 10 Mar 2023 08:32:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-IronPort-AV: E=McAfee;i="6500,9779,10644"; a="316332373" X-IronPort-AV: E=Sophos;i="5.98,249,1673942400"; d="scan'208";a="316332373" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10644"; a="710203908" X-IronPort-AV: E=Sophos;i="5.98,249,1673942400"; d="scan'208";a="710203908" Message-ID: Date: Fri, 10 Mar 2023 16:32:15 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.8.0 Content-Language: en-US To: Parav Pandit , "Michael S. Tsirkin" , Jiri Pirko Cc: "virtio-comment@lists.oasis-open.org" , "virtio-dev@lists.oasis-open.org" , "jasowang@redhat.com" , "cohuck@redhat.com" , "sgarzare@redhat.com" , "stefanha@redhat.com" , "nrupal.jani@intel.com" , "Piotr.Uminski@intel.com" , "hang.yuan@intel.com" , "virtio@lists.oasis-open.org" , "pasic@linux.ibm.com" , Shahaf Shuler , Max Gurtovoy References: <20230306175020-mutt-send-email-mst@kernel.org> <20230307121529-mutt-send-email-mst@kernel.org> From: "Zhu, Lingshan" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [virtio-dev] Re: [virtio-comment] [PATCH v10 00/10] Introduce device group and device management On 3/8/2023 3:31 AM, Parav Pandit wrote: >> From: Michael S. Tsirkin >> 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. I have submitted a series implementing "transport vq" which work for ADIs like SIOV devices, MST required a merge with admin q, so we are here. >>>> 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 > > 3. SR-IOV VF Live migration > 4. Above #1 to #3 for SIOV devices instead of SRIOV devices > > 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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org