RE: [virtio-comment] Re: [PATCH v3 6/8] admin: Add theory of operation for write recording commands

[Parav Pandit <parav@nvidia.com>]

> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, November 21, 2023 10:47 AM
> 
> On Fri, Nov 17, 2023 at 8:51âPM Parav Pandit <parav@nvidia.com> wrote:
> >
> >
> > > From: virtio-comment@lists.oasis-open.org
> > > <virtio-comment@lists.oasis- open.org> On Behalf Of Michael S.
> > > Tsirkin
> > > Sent: Friday, November 17, 2023 6:11 PM
> > >
> > > On Fri, Nov 17, 2023 at 12:22:59PM +0000, Parav Pandit wrote:
> > > >
> > > >
> > > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > > Sent: Friday, November 17, 2023 5:03 PM
> > > > > To: Parav Pandit <parav@nvidia.com>
> > > >
> > > > > > Somehow the claim of shadow vq is great without sharing any
> > > > > > performance
> > > > > numbers is what I don't agree with.
> > > > >
> > > > > It's upstream in QEMU. Test it youself.
> > > > >
> > > > We did few minutes back.
> > > > It results in a call trace.
> > > > Vhost_vdpa_setup_vq_irq crashes on list corruption on net-next.
> > >
> > > Wrong list for this bug report.
> > >
> > > > We are stopping any shadow vq tests on unstable stuff.
> > >
> > > If you don't want to benchmark against alternatives how are you
> > > going to prove your stuff is worth everyone's time?
> >
> > Comparing performance of the functional things count.
> > You suggest shadow vq, frankly you should post the grand numbers of
> shadow vq.
> 
> We need an apple to apple comparison. Otherwise you may argue with that,
> no?
> 
When the requirements are met the comparison can be made of the solution.
And I donât see that the basic requirements are matching for two different use cases.
So no point in discussing one OS specific implementation as reference point.
Otherwise I will end up adding vfio link in the commit log in next version as you are asking similar things here and being non neutral to your ask.

Anyway, please bring the perf data whichever you want to compare in another forum. It is not the criteria anyway.

> >
> > It is really not my role to report bug of unstable stuff and compare the perf
> against.
> 
> Qemu/KVM is highly relevant here no? And it's the way to develop the
> community. The shadow vq code is handy.
It is relevant for direct mapped device.
There is absolutely no point of converting virtio device to another virtualization layer and run again and get another virtio device.
So for direct mapping use case shadow vq is not relevant.
For other use cases, please continue.

> 
> Just an email to Qemu should be fine, we're not asking you to fix the bug.
> 
> Btw, how do you define stable? E.g do you think the Linus tree is stable?
> 
Basic test with iperf is not working. Crashing it.
All of this is complete unrelated discussion to this series to slow down the work.
I donât see any value.
Michael asked to do the test, we did, it does not work. Functionally broken code has no comparison.

> Thanks
> 
> >
> > We propose device context and provided the numbers you asked. Mostly
> wont be able to go farther than this.
> >
> > This publicly archived list offers a means to provide input to the
> > OASIS Virtual I/O Device (VIRTIO) TC.
> >
> > In order to verify user consent to the Feedback License terms and to
> > minimize spam in the list archive, subscription is required before
> > posting.
> >
> > Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> > List help: virtio-comment-help@lists.oasis-open.org
> > List archive: https://lists.oasis-open.org/archives/virtio-comment/
> > Feedback License:
> > https://www.oasis-open.org/who/ipr/feedback_license.pdf
> > List Guidelines:
> > https://www.oasis-open.org/policies-guidelines/mailing-lists
> > Committee: https://www.oasis-open.org/committees/virtio/
> > Join OASIS: https://www.oasis-open.org/join/
> >