> On Tue, Mar 5, 2024 at 4:21 AM Xinying Yu
> wrote:
> >
> > Of course, I am glad to do. And I need to clarify that our use case only
> support VIRTIO_F_NOTIFICATION_DATA transport feature on DPDK vDPA
> framework which the backend type is NET_CLIENT_DRIVER_VHOST_USER and
> use user_feature_bits. So the new feature add on vdpa_feature_bits will not
> under verified in our case. Not sure this meets your expectations?
>
> As long as the driver keeps using notification data it is not able to tell the
> difference between one scenario or another, so yes.
>
OK, I see. And the test result is OK, the feature negotiation correctly and
the use case passed.
> > One more thing, I would ask how do I get the full series patch? Do I copy
> > the
> RFC line by line from this link[1]?
> >
>
> lore.kernel.org is a good alternative as Thomas mentioned. Another good one
> IMO is b4, which allows you to download the series and apply with "git am"
> too using "b4 mbox <20240301134330.4191007-1-
> jonah.pal...@oracle.com>" (untested).
>
> https://pypi.org/project/b4/
>
> Thanks!
>
> For getting patches that you might have missed on the mailing list, I
> recommend lore.kernel.org :
>
>
> https://lore.kernel.org/qemu-devel/20240301134330.4191007-1-
> jonah.pal...@oracle.com/
>
> You can download mbox files there that you can apply locally with "git am".
>
> HTH,
>Thomas
Thanks to you and Thomas for the advice which works well.
> > Thanks,
> > Xinying
> >
> >
> > [1]
> > https://lists.nongnu.org/archive/html/qemu-devel/2024-
> 03/msg00090.html
> >
> >
> > From: Eugenio Perez Martin
> > Sent: Saturday, March 2, 2024 4:32 AM
> > To: Wentao Jia ; Rick Zhong
> > ; Xinying Yu
>
> > Cc: Jonah Palmer ; qemu-devel@nongnu.org
> > ; m...@redhat.com ;
> > jasow...@redhat.com ; si-wei@oracle.com
> > ; boris.ostrov...@oracle.com
> > ; raph...@enfabrica.net
> > ; kw...@redhat.com ;
> > hre...@redhat.com ; pa...@linux.ibm.com
> > ; borntrae...@linux.ibm.com
> > ; far...@linux.ibm.com
> > ; th...@redhat.com ;
> > richard.hender...@linaro.org ;
> > da...@redhat.com ; i...@linux.ibm.com
> > ; coh...@redhat.com ;
> > pbonz...@redhat.com ; f...@euphon.net
> > ; stefa...@redhat.com ;
> > qemu-bl...@nongnu.org ; qemu-
> s3...@nongnu.org
> > ; virtio...@lists.linux.dev
> >
> > Subject: Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA
> > support
> >
> > Hi Wentao / Rick / Xinying Yu,
> >
> > Would it work for you to test this series on your use cases, so we
> > make sure everything works as expected?
> >
> > Thanks!
> >
> > On Fri, Mar 1, 2024 at 2:44 PM Jonah Palmer
> wrote:
> > >
> > > The goal of these patches are to add support to a variety of virtio
> > > and vhost devices for the VIRTIO_F_NOTIFICATION_DATA transport
> > > feature. This feature indicates that a driver will pass extra data
> > > (instead of just a virtqueue's index) when notifying the corresponding
> device.
> > >
> > > The data passed in by the driver when this feature is enabled varies
> > > in format depending on if the device is using a split or packed
> > > virtqueue
> > > layout:
> > >
> > > Split VQ
> > > - Upper 16 bits: last_avail_idx
> > > - Lower 16 bits: virtqueue index
> > >
> > > Packed VQ
> > > - Upper 16 bits: 1-bit wrap counter & 15-bit last_avail_idx
> > > - Lower 16 bits: virtqueue index
> > >
> > > Also, due to the limitations of ioeventfd not being able to carry
> > > the extra provided by the driver, ioeventfd is left disabled for any
> > > devices using this feature.
> > >
> > > A significant aspect of this effort has been to maintain
> > > compatibility across different backends. As such, the feature is
> > > offered by backend devices only when supported, with fallback
> > > mechanisms where backend support is absent.
> > >
> >
> > Hi Wentao,
> >
