[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 ACCEPTcommand}\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 thedriver 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]