| Message ID | 20240301134330.4191007-1-jonah.palmer@oracle.com |
|---|---|
| Headers | show |
| Series | virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support | expand |
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,
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? 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]? Thanks, Xinying [1] https://lists.nongnu.org/archive/html/qemu-devel/2024-03/msg00090.html
On 05/03/2024 04.21, Xinying Yu wrote: > 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]? 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
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. > 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! > 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, >
> 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, > >