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