Re: [virtio-comment] Re: [RFC PATCH v2 1/2] Add virtio Admin Virtqueue specification

[Cornelia Huck <cohuck@redhat.com>]

On Tue, Aug 03 2021, Max Gurtovoy <mgurtovoy@nvidia.com> wrote:

> On 8/3/2021 9:51 AM, Cornelia Huck wrote:
>> On Tue, Aug 03 2021, Jason Wang <jasowang@redhat.com> wrote:
>>
>>> 在 2021/8/3 下午2:28, Cornelia Huck 写道:
>>>> On Mon, Aug 02 2021, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>>>>
>>>>> On Mon, Aug 02, 2021 at 07:03:11PM +0300, Max Gurtovoy wrote:
>>>>>> There is no much bits left in the generic feature field for all the features
>>>>>> we would like to add.
>>>>>> I mentioned only 5-6 in the above example and it will bring us to bit 46
>>>>>> already.
>>>>>>
>>>>>> please think of 5-10 years from today.
>>>>>>
>>>>> IIUC nothing prevents adding more once we exhaust 64 bits. IMHO it's actually
>>>>> pretty important to make sure the feature negotiation works well
>>>>> and covers relevant usecases. If we have limitations preventing that
>>>>> I'd like to at least try to fix that not replacing feature negotiation with
>>>>> something else.
>>>> I recall that we had a discussion about that years ago when we
>>>> introduced VERSION_1; we explicitly agreed that we can extend features
>>>> beyond 64 bit once we need it. (A quick search did not turn up that mail
>>>> exchange, though.)
>>>>
>>> E.g PCI transport has feature_select.
>>>
>>>           le32 device_feature_select;     /* read-write */
>>>           le32 device_feature;            /* read-only for driver */
>>>           le32 driver_feature_select;     /* read-write */
>>>           le32 driver_feature;            /* read-write */
>>>
>>> Technically it can support 32*32 different features.
>> MMIO uses a similar scheme; CCW uses
>>
>> struct virtio_feature_desc {
>>         le32 features;
>>         u8 index;
>> };
>>
>> so there's plenty of room to spare.
>
> Feature negotiation can be done in admin q level. You don't want this 
> branches in the spec per each transport or device type.

This has nothing to do with transports. We only wanted to demonstrate
that all of the transports can be extended, so feature bits are not a
scarce resource.

>
> We have an admin command to get all device admin q features and we can 
> create a command to set all the driver supported.
>
> Again, I don't see the point of doing that. If a device is supporting 
> command_A, the driver should be able to use it. Telling the device "hi, 
> I'm going to use command_A in the future" is redundant.
>
> The device knows already how to handle it.

If the driver negotiates a certain feature, it can mean that the device
can make certain optimizations.

That's not a particularily exotic pattern.


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/