[virtio-dev] RE: [virtio-comment] [PATCH 5/5] virtio-pci: implement VIRTIO_F_QUEUE_STATE

Parav Pandit
2023-09-12T06:50:34Z

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Tuesday, September 12, 2023 12:08 PM
>
> On 9/12/2023 1:51 PM, Parav Pandit wrote:
> >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >> Sent: Tuesday, September 12, 2023 9:19 AM
> >>
> >> On 9/11/2023 7:50 PM, Parav Pandit wrote:
> >>>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >>>> Sent: Monday, September 11, 2023 3:03 PM By the way, do you see
> >>>> anything we need to improve in this series?
> >>> Admin commands for passthrough devices of [1] is comprehensive
> >>> proposal
> >> covering all the aspects.
> >>> To me [1] is superset work that covers all needed functionality and
> >>> downtime
> >> aspects.
> >>> I plan to improve [1] with v1 this week by extending device context
> >>> and
> >> addressing other review comments.
> >>> [1]
> >>> https://lists.oasis-open.org/archives/virtio-comment/202309/msg00061
> >>> .h
> >>> tml
> >> I am not sure, we have discussed a lot about the potential issues in
> >> the treads. I guess we should resolve them first. E.g., nested use cases.
> > You are using nesting use case as the _only_ use case and attempt to steer
> using that.
> > Not right.
> >
> > If you want to discuss, then lets have both the use cases, attempt to converge
> and if we can its really good.
> > If we cannot, both requirements should be handled differently.
> Isn't nested a clear use case that should be supported?

Most users who care for running real applications and real performance, have not asked for nesting.
It is not mandatory case; it may be required for some users.
I don’t know who needs M level nesting and how cpu also support its acceleration etc to run some reasonable workload.