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

Paolo Abeni <[email protected]>
Newsgroups dev.linux.lists.virtio-comment
Message-ID <[email protected]>
Hi all,

On 5/6/25 10:56 AM, Parav Pandit wrote:
>> From: Michael S. Tsirkin <[email protected]>
>> Sent: Tuesday, May 6, 2025 1:26 PM
>>> There are few proposals on table.
>>>
>>> 1. From Paolo,
>>> - 0 to 23, and 50 to 127 Feature bits for the specific device type
>>> + 0 to 23, and 46 to 127 Feature bits for the specific device type
>>>
>>> This does not have good reason of why it should still be 127.
>>>
>>> 2. From me:
>>> - 0 to 23, and 50 to 127 Feature bits for the specific device type
>>> + 0 to 23, and 45 to 64 Feature bits for the specific device type
>>>
>>> This is an extension of Paolo, to justify that implementing feature bits is
>> extremely hard even for experts as pointed by Paolo.
>>> It is worth to not extend it further.
>>> RSS can be negotiated via new bit 44 in future bit as OR of 44 and 64 so that
>> more wider users (Linux, freebsd, qnx, Windows, dpdk pmd) can pick 44.
>>>
>>> 3. From me:
>>> Keep the feature bits encoding as is up to 127 bits, because may be there is
>> (unknown and weird) value in having 127 feature bits.
>>> (unknown because the reasoning of #1 and #3 mismatch).
>>> In that case,
>>> VIRTIO_NET_CTRL_GUEST_OFFLOADS command text to be updated to
>> indicate
>>> feature fits A to D map to VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.offloads
>> bits A' to D'.
>>>
>>> I am fine with option #2 and #3.
>>> Doing #1 for sure is wrong.
>>> Wrong because it delays the problem of #1 from this to another feature [A]
>> who's voting already completed.
>>>
>>> [A]
>>> https://lore.kernel.org/virtio-
>> comment/DM4PR18MB4269F73B786E83EF68A70F
>>> [email protected]/T/#t
>>
>>
>> #3 seems more conservate.
> 
> 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

using bits 46-39 for UDP tunnel offloads and likely bit 45 for
VIRTIO_NET_F_OUT_NET_HEADER.

The VIRTIO_NET_F_CTRL_GUEST_OFFLOADS mapping should be specified after
eventually a new offload feature will be defined using a bit >= 64.

Am I correct?

Thanks,

Paolo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.