Re: [virtio-comment] About the plan of Admin Queue

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 6/30/2023 5:14 PM, Xuan Zhuo wrote:
> On 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.html
>>>>>>> I review the patch, that is for S-IOV, right?
>>>>>> Yes, for SIOV and other similar devices
>>>>>>> I 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.
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 help
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.
>
>
>> Thanks
>>> Thanks.
>>>
>>>
>>>
>>>
>>>> Thanks
>>>>> Thanks.
>>>>>
>>>>>
>>>>>> Thanks
>>>>>>> Thanks.
>>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Zhu Lingshan
>>>>>>>>> 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/
>>>>>>>>
>>>>>>> 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/