Re: [PATCH v1] virtio-net: Fix to avoid using reserved feature bits

[Paolo Abeni <pabeni@redhat.com>]

On 5/7/25 11:57 AM, Paolo Abeni wrote:
> On 5/6/25 6:20 PM, Parav Pandit wrote:
>> From: Paolo Abeni <pabeni@redhat.com Sent: Tuesday, May 6, 2025 9:10 PM
>>> On 5/6/25 5:00 PM, Parav Pandit wrote:
>>>> From: Paolo Abeni <pabeni@redhat.com Sent: Tuesday, May 6, 2025 8:09 PM
>>>>> On 5/6/25 10:56 AM, Parav Pandit wrote:
>>>>>> Are you good with #3?
>>>>>
>>>>> I'm sorry for the latency. Let me double check to avoid possible
>>>>> misunderstanding; #3 means:
>>>>>
>>>>> - 0 to 23, and 50 to 127 Feature bits for the specific device type
>>>>> + 0 to 23, and 45 to 127 Feature bits for the specific device type
>>>>>
>>>> No change in above feature bits.
>>>>
>>>>> using bits 46-39 for UDP tunnel offloads and likely bit 45 for
>>>>> VIRTIO_NET_F_OUT_NET_HEADER.
>>>>>
>>>> This also to use bit 69 as proposed.
>>>>
>>>>> The VIRTIO_NET_F_CTRL_GUEST_OFFLOADS mapping should be specified
>>>>> after eventually a new offload feature will be defined using a bit >= 64.
>>>>>
>>>> No. UDP tunnel feature bits 65 to 68 maps to command bits 46,47,48,49.
>>>> This is the only description change in
>>> VIRTIO_NET_F_CTRL_GUEST_OFFLOADS command.
>>>> Would it work?
>>>
>>> AFAICT, yes, it should work.
>>>
>>> But it will not avoid the immediate need to expand the virtio features
>>> negotiation above 64 bits, with the already mentioned complexity.
>>>
>>> I would preferably avoid that, if possible: I restarted this thread with such a
>>> goal.
>>>
>> In that case we should adopt #2.
> 
> Do we have quorum? Should I send a patch?

As per off-list discussion with Michel, there is no agreement on
reserved bits re-use.

That means the only available option is #3 above.

@Parav, would you send a patch to fix the offloads <> features mapping,
or do you prefer I'll do it?

Thanks,

Paolo