All of lore.kernel.org
 help / color / mirror / Atom feed
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,
> >


      reply	other threads:[~2024-03-06  9:17 UTC|newest]

Thread overview: 26+ 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
2024-03-05  3:21   ` Xinying Yu
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.