> On Tue, Mar 5, 2024 at 4:21 AM Xinying Yu <[email protected]> > 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- > [email protected]>" (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- > [email protected]/ > > 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 <[email protected]> > > Sent: Saturday, March 2, 2024 4:32 AM > > To: Wentao Jia <[email protected]>; Rick Zhong > > <[email protected]>; Xinying Yu > <[email protected]> > > Cc: Jonah Palmer <[email protected]>; [email protected] > > <[email protected]>; [email protected] <[email protected]>; > > [email protected] <[email protected]>; [email protected] > > <[email protected]>; [email protected] > > <[email protected]>; [email protected] > > <[email protected]>; [email protected] <[email protected]>; > > [email protected] <[email protected]>; [email protected] > > <[email protected]>; [email protected] > > <[email protected]>; [email protected] > > <[email protected]>; [email protected] <[email protected]>; > > [email protected] <[email protected]>; > > [email protected] <[email protected]>; [email protected] > > <[email protected]>; [email protected] <[email protected]>; > > [email protected] <[email protected]>; [email protected] > > <[email protected]>; [email protected] <[email protected]>; > > [email protected] <[email protected]>; qemu- > [email protected] > > <[email protected]>; [email protected] > > <[email protected]> > > 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 <[email protected]> > 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, > >
