From: Xinying Yu <xinying.yu@nephogine.com>
To: Eugenio Perez Martin <eperezma@redhat.com>,
Thomas Huth <thuth@redhat.com>
Cc: Wentao Jia <wentao.jia@nephogine.com>,
Rick Zhong <zhaoyong.zhong@nephogine.com>,
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
Date: Wed, 6 Mar 2024 09:17:02 +0000 [thread overview]
Message-ID: <PH0PR13MB5682B1B136F763453D0343AC88212@PH0PR13MB5682.namprd13.prod.outlook.com> (raw)
In-Reply-To: <CAJaqyWdr5PyxNJ2D_HMk8U2xEpfPTebi4d91V3ONs91yNibwOw@mail.gmail.com>
> 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,
> >
prev parent reply other threads:[~2024-03-06 9:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 13:43 [RFC 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support Jonah Palmer
2024-03-01 13:43 ` [RFC 1/8] virtio/virtio-pci: Handle extra notification data Jonah Palmer
2024-03-01 19:31 ` Eugenio Perez Martin
2024-03-04 17:04 ` Jonah Palmer
2024-03-04 17:24 ` Eugenio Perez Martin
2024-03-04 17:32 ` Jonah Palmer
2024-03-01 19:55 ` Eugenio Perez Martin
2024-03-04 17:08 ` Jonah Palmer
2024-03-01 13:43 ` [RFC 2/8] virtio-pci: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA Jonah Palmer
2024-03-01 19:44 ` Eugenio Perez Martin
2024-03-01 13:43 ` [RFC 3/8] virtio-mmio: Handle extra notification data Jonah Palmer
2024-03-01 13:43 ` [RFC 4/8] virtio-mmio: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA Jonah Palmer
2024-03-01 13:43 ` [RFC 5/8] virtio-ccw: Handle extra notification data Jonah Palmer
2024-03-02 15:33 ` Thomas Huth
2024-03-01 13:43 ` [RFC 6/8] virtio-ccw: Lock ioeventfd state with VIRTIO_F_NOTIFICATION_DATA Jonah Palmer
2024-03-02 15:35 ` Thomas Huth
2024-03-01 13:43 ` [RFC 7/8] vhost/vhost-user: Add VIRTIO_F_NOTIFICATION_DATA to vhost feature bits Jonah Palmer
2024-03-01 20:04 ` Eugenio Perez Martin
2024-03-04 17:12 ` Jonah Palmer
2024-03-01 13:43 ` [RFC 8/8] virtio: Add VIRTIO_F_NOTIFICATION_DATA property definition Jonah Palmer
2024-03-01 20:05 ` Eugenio Perez Martin
2024-03-01 20:32 ` [RFC 0/8] virtio,vhost: Add VIRTIO_F_NOTIFICATION_DATA support Eugenio Perez Martin
[not found] ` <PH0PR13MB56827829C8502484EACF080D88222@PH0PR13MB5682.namprd13.prod.outlook.com>
2024-03-05 6:56 ` Thomas Huth
2024-03-05 8:09 ` Eugenio Perez Martin
2024-03-06 9:17 ` Xinying Yu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PH0PR13MB5682B1B136F763453D0343AC88212@PH0PR13MB5682.namprd13.prod.outlook.com \
--to=xinying.yu@nephogine.com \
--cc=boris.ostrovsky@oracle.com \
--cc=borntraeger@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=eperezma@redhat.com \
--cc=fam@euphon.net \
--cc=farman@linux.ibm.com \
--cc=hreitz@redhat.com \
--cc=iii@linux.ibm.com \
--cc=jasowang@redhat.com \
--cc=jonah.palmer@oracle.com \
--cc=kwolf@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=raphael@enfabrica.net \
--cc=richard.henderson@linaro.org \
--cc=si-wei.liu@oracle.com \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
--cc=virtio-fs@lists.linux.dev \
--cc=wentao.jia@nephogine.com \
--cc=zhaoyong.zhong@nephogine.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).