Re: [RFC PATCH] Introduce admin virtqueue as a new transport

[Max Gurtovoy <mgurtovoy@nvidia.com>]

On 8/4/2021 4:37 AM, Jason Wang wrote:
> å 2021/8/3 äå8:40, Max Gurtovoy åé:
> > > +Sometimes it's hard to implement the device in a transport specific
> > > +method. One example is that a physical device may try to present
> > > +multiple virtual devices with a limited transport specific
> > > +resources. Another example is to implement virtual devices which is
> > > +transport independent. In those cases, the admin virtqueue provided by
> > > +the management device could be used to replace the transport specific
> > > +method to implement the virtual device. Then the presenting of the
> > > +virtual device is done through the cooperation between the admin
> > > +virtqueue and the driver.
> >
> > maybe it's me, but I can't understand how admin queue is a transport.
>
>
> The transport is the method that provides basic facility. In this 
> proposal, the admin virtqueue is used to provide basic facility for 
> the virtual device. That is to say, it's the transport for virtual 
> device.
>
>
> > And how can I use admin queue transport to migrate VFs that are 
> > controlled by virtio PCI PF.
>
>
> This live migration support and the admin virtqueue transport are 
> orthogonal. The main motivation of this proposal is used for 
> implementing virtual device transport via admin virtqueue. It's not 
> hard to add new commands for doing live migration for the virtual 
> device, I don't do that since I believe it's expected to be addressed 
> in your proposal.

so why do you call it in the same name that I used in my RFC ? This is 
confusing and causing problems.

You are working on a parallel feature and reviewing my RFC as if it was 
instead of your proposal.

IIUC, in your proposal a non SRIOV device parent will create admin queue 
and using this admin queue you'll be able to create children devices and 
their transport will be admin queue.

That means that the configuration cycles will be trapped by the parent 
device somehow.

This also means we need to merge my RFC first to create infrastructure 
for this RFC.

For admin management that you'll need probably virtio-cli tool from user 
space.

So this proposal is complementary to mine. Your management device will 
negotiate "my" admin_queue feature and you'll need to add more commands 
to this admin queue that are probably in transport specific domain to 
create children.

You do need to handle the configuration cycles that this management 
parent device will need to support.


> For virtual device, it's a independent virtio device that could be 
> assigned to secure DMA context/domain, it is functional equivalent 
> ADI or SF. The difference is that it can work with or without platform 
> support (SIOV or PASID).
>
>
> > And why the regular admin queue that is part of the device queues 
> > can't fit to your needs ?
>
>
> For "regular admin queue", did you mean your proposal. Actually, it's 
> not conflict, we can unify the interface though the motivation is 
> different.
>
>
> > Can you explain your needs ? is it to create a vDPA device from some 
> > SW interface ?
>
>
> As stated in the patch, the needs are:
>
> - Presenting virtual devices with limited transport specific resources
> - Presenting virtual devices without platform support (e.g SR-IOV or 
> SIOV)
>
> We want virtio to have hyper-scalability via slicing at virtio level. 
> It's not directly related to vDPA.
>
> For vDPA, vendor are freed to have their own technology to be hyper 
> scalable (e.g SF, ADI or other stuffs).
>
> Thanks
>
>
> > I don't follow.