> On Tue, Mar 5, 2024 at 4:21 AM Xinying Yu <xinying...@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.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 <epere...@redhat.com> > > Sent: Saturday, March 2, 2024 4:32 AM > > To: Wentao Jia <wentao....@nephogine.com>; Rick Zhong > > <zhaoyong.zh...@nephogine.com>; Xinying Yu > <xinying...@nephogine.com> > > Cc: Jonah Palmer <jonah.pal...@oracle.com>; qemu-devel@nongnu.org > > <qemu-devel@nongnu.org>; m...@redhat.com <m...@redhat.com>; > > jasow...@redhat.com <jasow...@redhat.com>; si-wei....@oracle.com > > <si-wei....@oracle.com>; boris.ostrov...@oracle.com > > <boris.ostrov...@oracle.com>; raph...@enfabrica.net > > <raph...@enfabrica.net>; kw...@redhat.com <kw...@redhat.com>; > > hre...@redhat.com <hre...@redhat.com>; pa...@linux.ibm.com > > <pa...@linux.ibm.com>; borntrae...@linux.ibm.com > > <borntrae...@linux.ibm.com>; far...@linux.ibm.com > > <far...@linux.ibm.com>; th...@redhat.com <th...@redhat.com>; > > richard.hender...@linaro.org <richard.hender...@linaro.org>; > > da...@redhat.com <da...@redhat.com>; i...@linux.ibm.com > > <i...@linux.ibm.com>; coh...@redhat.com <coh...@redhat.com>; > > pbonz...@redhat.com <pbonz...@redhat.com>; f...@euphon.net > > <f...@euphon.net>; stefa...@redhat.com <stefa...@redhat.com>; > > qemu-bl...@nongnu.org <qemu-bl...@nongnu.org>; qemu- > s3...@nongnu.org > > <qemu-s3...@nongnu.org>; virtio...@lists.linux.dev > > <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 <jonah.pal...@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, > >
