[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] About the plan of Admin Queue
On 6/30/2023 5:14 PM, Xuan Zhuo wrote:
I understand once a customer orders a new NIC, you wants to present the NIC to the host. However you only owns the DPU and the customer owns the host, that means this creation and hot plug must be transparent to the host and there may not be a host driver helpOn Fri, 30 Jun 2023 16:32:44 +0800, "Zhu, Lingshan" <lingshan.zhu@intel.com> wrote:On 6/30/2023 3:56 PM, Xuan Zhuo wrote:On Fri, 30 Jun 2023 15:54:40 +0800, "Zhu, Lingshan" <lingshan.zhu@intel.com> wrote:On 6/30/2023 3:46 PM, Xuan Zhuo wrote:On Fri, 30 Jun 2023 14:19:47 +0800, "Zhu, Lingshan" <lingshan.zhu@intel.com> wrote:On 6/30/2023 1:54 PM, Xuan Zhuo wrote:On Tue, 20 Jun 2023 16:11:12 +0800, "Zhu, Lingshan" <lingshan.zhu@intel.com> wrote:On 6/20/2023 2:44 PM, Xuan Zhuo wrote:Hi, hi, I would want to know some plans and progress about admin queue. At the current spec, it seems that there is only one framework and no specific commands. I'd like to know if anyone is currently working on this and what the plans are. We also faced some similar issues, and we think admin queue is a good way to manage sr-iov. Thanks.I plan to rebase original transport vq on admin vq. https://lists.oasis-open.org/archives/virtio-comment/202208/msg00140.htmlI review the patch, that is for S-IOV, right?Yes, for SIOV and other similar devicesI think it is good. I would if all is configured by the transport vq/admin vq from the OS?For SIOV ADIs, this transport vq is the transport layer, so they are configured by the OS through transport vq.Can we create a managed dev from the backend? Such as, the DPU sends a command to the driver, then the driver creates a new managed dev.I think the group owner, usually the PCI PF is the management device.I mean the DPU hot-plug a new device. Not the managament device create a new device. The managament device is in the OS, we want the device is plugged by the DPU.The PCI management(SIOV group owner) device is on the DPU, when create an ADI, OS send a command to the DPU/PF through transport vq, then the PF hot plugged in a new ADI through the transport vq specific channel. Or did I misunderstand your question?Your first step is the os send a command. Right? Can we let the DPU notify the driver to create a new devicer from the backend? The key point is who want to create a new device.DPU can come with a certain number of pre-created ADIs, just make sure the orchestration SW is aware of their device IDs. If you want the DPU randomly create ADIs and notify the driver, I think we need interrupt, e.g., re-use config interrupt. But why DPU wants to create and hot plug in a device to a guest? Shall the host handle that or DPU pre-create then expose to baremteal machines?In your scenario, the supervisor is on the os, which controls the DPU to create new devices. In the cloud scenario, the vendor manager is in the DPU, and the entire host is for users. Of course, there are situations where the vendor manager are in the HOST. But for bare metal machines, the host belongs to the customer, the vendor manager is only in the DPU. So when the customers buy a new nic for the host, the vendor manager will plug a device to the host from the DPU.
handling an interrupt/probe.However this is not PCI which has a tree/switch and can enumerate devices to the
host by spanning the device across the PCI hierarchy. To address an ADI, there is only a device_id.So, do you mind share how your DPU offload the device model? What kind of device your DPU provide
to the host? Lets see whether DPU can mediate this by its own?
Thanks.ThanksThanks.ThanksThanks.ThanksThanks.Thanks, Zhu LingshanThis 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/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/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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]