qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support


From: Eugenio Perez Martin
Subject: Re: [RFC 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support
Date: Tue, 5 Mar 2024 09:09:54 +0100

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,
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]