> On Tue, Mar 5, 2024 at 4:21 AM Xinying Yu <xinying.yu@nephogine.com>
> 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.palmer@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.palmer@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 <eperezma@redhat.com>
> > Sent: Saturday, March 2, 2024 4:32 AM
> > To: Wentao Jia <wentao.jia@nephogine.com>; Rick Zhong
> > <zhaoyong.zhong@nephogine.com>; Xinying Yu
> <xinying.yu@nephogine.com>
> > Cc: Jonah Palmer <jonah.palmer@oracle.com>; qemu-devel@nongnu.org
> > <qemu-devel@nongnu.org>; mst@redhat.com <mst@redhat.com>;
> > jasowang@redhat.com <jasowang@redhat.com>; si-wei.liu@oracle.com
> > <si-wei.liu@oracle.com>; boris.ostrovsky@oracle.com
> > <boris.ostrovsky@oracle.com>; raphael@enfabrica.net
> > <raphael@enfabrica.net>; kwolf@redhat.com <kwolf@redhat.com>;
> > hreitz@redhat.com <hreitz@redhat.com>; pasic@linux.ibm.com
> > <pasic@linux.ibm.com>; borntraeger@linux.ibm.com
> > <borntraeger@linux.ibm.com>; farman@linux.ibm.com
> > <farman@linux.ibm.com>; thuth@redhat.com <thuth@redhat.com>;
> > richard.henderson@linaro.org <richard.henderson@linaro.org>;
> > david@redhat.com <david@redhat.com>; iii@linux.ibm.com
> > <iii@linux.ibm.com>; cohuck@redhat.com <cohuck@redhat.com>;
> > pbonzini@redhat.com <pbonzini@redhat.com>; fam@euphon.net
> > <fam@euphon.net>; stefanha@redhat.com <stefanha@redhat.com>;
> > qemu-block@nongnu.org <qemu-block@nongnu.org>; qemu-
> s390x@nongnu.org
> > <qemu-s390x@nongnu.org>; virtio-fs@lists.linux.dev
> > <virtio-fs@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 <jonah.palmer@oracle.com>
> 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,
> >