OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] RE: [PATCH v5 2/7] Introduce admin command set



On 5/17/2022 1:08 PM, Cornelia Huck wrote:
On Mon, May 16 2022, Parav Pandit <parav@nvidia.com> wrote:

Hi Michael,

From: Michael S. Tsirkin <mst@redhat.com>
Sent: Sunday, May 15, 2022 11:24 AM
[..]

+\subsection{VIRTIO ADMIN DEVICE CAPS ACCEPT
command}\label{sec:Basic
+Facilities of a Virtio Device / Admin command set / VIRTIO ADMIN
+DEVICE CAPS ACCEPT command}
+
+The VIRTIO_ADMIN_DEVICE_CAPS_ACCEPT command is used by the
driver to acknowledge those admin capabilities it understands and wishes to
use.


ok so we have a protocol here, kind of like feature negotiation. Please write
its description.
e.g. is it ok to change accepted caps? when? can device change its caps etc
etc etc.

Avoiding this kind of spec work is exactly why me and jason keep telling you
to consider just using features instead. Add a 64 bit admin features field to
the PCI transport and be done with it. CCW and MMIO already have feature
selector so it's trivial to add feature bits.

As we begin to scale with the device, adding more and more registers like this demands more on-device real estate to comply to the PCI standards.

And therefore, things are queried/accessed rare or occasionally, are better accessed via a queue interface.

One can argue that admin VQ is proposed only for the mgmt. functions so having this cfg register for PF is enough.

However, AQ may find some usage in the VF/SF themselves down the road.
Hence, keeping the cap exchange transport this way is more optimal.

Max has called out this AQ rationale in 4 or 5 points in the cover letter.
I'm not against using a queue, but why not use feature bits for
capabilities? As Michael said, the infrastructure for that is already in
place.

It's not scalable.

After few features we'll add, we'll regret we ever did it.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]