Re: [Patch v1 3/3] vdpa/mlx5: Add multiqueue support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 12, 2021 at 12:55 PM Eli Cohen <elic@xxxxxxxxxx> wrote:
>
> On Thu, Aug 12, 2021 at 11:19:19AM +0800, Jason Wang wrote:
> >
> > 在 2021/8/11 下午7:04, Eli Cohen 写道:
> > > On Wed, Aug 11, 2021 at 04:37:44PM +0800, Jason Wang wrote:
> > > > 在 2021/8/11 下午3:53, Eli Cohen 写道:
> > > > > > One thing need to solve for mq is that the:
> > > > > >
> > > > > >
> > > > > > > +static u16 ctrl_vq_idx(struct  mlx5_vdpa_dev *mvdev)
> > > > > > > +{
> > > > > > > +     return 2 *  mlx5_vdpa_max_qps(mvdev->max_vqs);
> > > > > > > +}
> > > > > > We should handle the case when MQ is supported by the device but not the
> > > > > > driver.
> > > > > >
> > > > > > E.g in the case when we have 2 queue pairs:
> > > > > >
> > > > > > When MQ is enabled, cvq is queue 4
> > > > > >
> > > > > > When MQ is not enabled, cvq is queue 2
> > > > > >
> > > > > There's some issue with this. I get callbacks targeting specific
> > > > > virtqueues before features negotiation has been completed.
> > > > >
> > > > > Specifically, I get set_vq_cb() calls. At this point I must know the
> > > > > control vq index.
> > > >
> > > > So I think we need do both:
> > > >
> > > > 1) At one hand, it's a bug for the userspace to use vq_index before feature
> > > > is negotiated
> > > >
> > > > (looks like a bug in my cvq series that will call SET_VRING_CALL before
> > > > feature is negotiate, which I will look).
> > > >
> > > > 2) At the other hand, the driver should be able to deal with that
> > > >
> > > All I can do is drop callbacks for VQs before features negotation has
> > > been completed.
> >
> >
> > Or just leave queue index 0, 1 work.
> >
> > Since it is not expected to be changed.
> >
>
> Right, will do.
>
> >
> > >
> > > > > I think the CVQ index must not depend on the negotiated features but
> > > > > rather depend of the value the device driver provides in the call to
> > > > > _vdpa_register_device().
> > > >
> > > > At the virtio level, it's too late to change that and it breaks the backward
> > > > compatibility.
> > > >
> > > > But at the vDPA level, the under layer device can map virtio cvq to any of
> > > > it's virtqueue.
> > > >
> > > > E.g map cvq (index 2) to mlx5 cvq (the last).
> > > >
> > > I am not following you here. I still don't know what index is cvq.
> >
> >
> > Right, we still need to wait for the feature being negotiated in order to
> > proceed.
> >
>
> So to summarise, before feature negotiation complete, I accept calls
> referring to VQs only for indices 0 and 1.
> After feature negotiation complete I know CVQ index and will accept
> indices 0 to cvq index.

I don't get this "accept indices 0 to cvq index".

Thanks

>
> > Thanks
> >
> >
> > >
> > > > Thanks
> > > >
> > > >
> >
>

_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization




[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux