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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 07, 2025 at 11:57:26AM +0200, 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?

I'm curious how hard is 128 bit support, gimme a couple
of days to try and maybe post a patch, just for comparison.