Re: [PATCH 00/10] vhost/qemu: thread per IO SCSI vq

[Jason Wang]

On 2020/11/18 下午2:57, Mike Christie wrote:
> On 11/17/20 11:17 PM, Jason Wang wrote:
> > On 2020/11/18 上午12:40, Stefan Hajnoczi wrote:
> > > On Thu, Nov 12, 2020 at 05:18:59PM -0600, Mike Christie wrote:
> > > > The following kernel patches were made over Michael's vhost branch:
> > > >
> > > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git/log/?h=vhost__;!!GqivPVa7Brio!MzCv3wdRfz5dltunazRWGCeUkMg91pPEOLpIivsebLX9vhYDSi_E1V36e9H0NoRys_hU$
> > > > and the vhost-scsi bug fix patchset:
> > > >
> > > > https://urldefense.com/v3/__https://lore.kernel.org/linux-scsi/20201112170008.GB1555653@stefanha-x1.localdomain/T/*t__;Iw!!GqivPVa7Brio!MzCv3wdRfz5dltunazRWGCeUkMg91pPEOLpIivsebLX9vhYDSi_E1V36e9H0NmuPE_m8$
> > > > And the qemu patch was made over the qemu master branch.
> > > >
> > > > vhost-scsi currently supports multiple queues with the num_queues
> > > > setting, but we end up with a setup where the guest's scsi/block
> > > > layer can do a queue per vCPU and the layers below vhost can do
> > > > a queue per CPU. vhost-scsi will then do a num_queue virtqueues,
> > > > but all IO gets set on and completed on a single vhost-scsi thread.
> > > > After 2 - 4 vqs this becomes a bottleneck.
> > > >
> > > > This patchset allows us to create a worker thread per IO vq, so we
> > > > can better utilize multiple CPUs with the multiple queues. It
> > > > implments Jason's suggestion to create the initial worker like
> > > > normal, then create the extra workers for IO vqs with the
> > > > VHOST_SET_VRING_ENABLE ioctl command added in this patchset.
> > > How does userspace find out the tids and set their CPU affinity?
> > >
> > > What is the meaning of the new VHOST_SET_VRING_ENABLE ioctl? It doesn't
> > > really "enable" or "disable" the vq, requests are processed regardless.
> >
> > Actually I think it should do the real "enable/disable" that tries to follow 
> > the virtio spec.
> What does real mean here?


I think it means when a vq is disabled, vhost won't process any request 
from that virtqueue.


> For the vdpa enable call for example, would it be like
> ifcvf_vdpa_set_vq_ready where it sets the ready bit or more like 
> mlx5_vdpa_set_vq_ready
> where it can do some more work in the disable case?


For vDPA, it would be more complicated.

E.g for IFCVF, it just delay the setting of queue_enable when it get 
DRIVER_OK. Technically it can passthrough the queue_enable to the 
hardware as what mlx5e did.


> For net and something like ifcvf_vdpa_set_vq_ready's design would we have
> vhost_ring_ioctl() set some vhost_virtqueue enable bit. We then have some helper
> vhost_vq_is_enabled() and some code to detect if userspace supports the new 
> ioctl.


Yes, vhost support backend capability. When userspace negotiate the new 
capability, we should depend on SET_VRING_ENABLE, if not we can do 
vhost_vq_is_enable().


> And then in vhost_net_set_backend do we call vhost_vq_is_enabled()? What is done
> for disable then?


It needs more thought, but the question is not specific to 
SET_VRING_ENABLE. Consider guest may zero ring address as well.

For disabling, we can simply flush the work and disable all the polls.


> It doesn't seem to buy a lot of new functionality. Is it just
> so we follow the spec?


My understanding is that, since spec defines queue_enable, we should 
support it in vhost. And we can piggyback the delayed vq creation with 
this feature. Otherwise we will duplicate the function if we want to 
support queue_enable.


> Or do you want it work more like mlx5_vdpa_set_vq_ready? For this in 
> vhost_ring_ioctl
> when we get the new ioctl we would call into the drivers and have it start 
> queues
> and stop queues? For enable, what we you do for net for this case?


Net is something different, we can simply use SET_BACKEND to disable a 
specific virtqueue without introducing new ioctls. Notice that, net mq 
is kind of different with scsi which have a per queue pair vhost device, 
and the API allows us to set backend for a specific virtqueue.


> For disable,
> would you do something like vhost_net_stop_vq (we don't free up anything 
> allocated
> in vhost_vring_ioctl calls, but we can stop what we setup in the net driver)?


It's up to you, if you think you should free the resources you can do that.


> Is this useful for the current net mq design or is this for something like where
> you would do one vhost net device with multiple vqs?


I think SET_VRING_ENABLE is more useful for SCSI since it have a model 
of multiple vqs per vhost device.


> My issue/convern is that in general these calls seems useful, but we don't 
> really
> need them for scsi because vhost scsi is already stuck creating vqs like how it 
> does
> due to existing users. If we do the ifcvf_vdpa_set_vq_ready type of design where
> we just set some bit, then the new ioctl does not give us a lot. It's just an 
> extra
> check and extra code.
>
> And for the mlx5_vdpa_set_vq_ready type of design, it doesn't seem like it's 
> going
> to happen a lot where the admin is going to want to remove vqs from a running 
> device.


In this case, qemu may just disable the queues of vhost-scsi via 
SET_VRING_ENABLE and then we can free resources?


> And for both addition/removal for scsi we would need code in virtio scsi to 
> handle
> hot plug removal/addition of a queue and then redoing the multiqueue mappings 
> which
> would be difficult to add with no one requesting it.


Thanks


>