RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage

From
Parav Pandit <>
Date
2023-10-25T09:55:25+00:00
ID
Thread
RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage
Hi Cornelia,

> From: Parav Pandit <>
> Sent: Monday, October 23, 2023 8:52 PM
> To: Cornelia Huck <>; Michael S. Tsirkin
> <>
> Cc: ; ;
> ; Shahaf Shuler <>
> Subject: RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling
> virtqueue after DRIVER_OK stage
> 
> 
> > From:  <-
> > open.org> On Behalf Of Cornelia Huck
> > Sent: Monday, October 23, 2023 8:31 PM
> >
> > On Mon, Oct 23 2023, Parav Pandit <> wrote:
> >
> > >> From: Cornelia Huck <>
> > >> Sent: Monday, October 23, 2023 7:58 PM
> > >
> > >> On Mon, Oct 23 2023, Parav Pandit <> wrote:
> > >>
> > >> >> From: 
> > >> >> <- open.org> On Behalf Of Cornelia
> > >> >> Huck
> > >> >> Sent: Monday, October 23, 2023 7:27 PM
> > >> >
> > >> >> Well, there are  still comments from me here that post-date v4
> > >> >> (please wait for a bit before posting another version!), so I'll
> > >> >> continue waiting for them to be addressed first.
> > >> > The last one was [1].
> > >> > Which I replied few days ago at [2].
> > >> >
> > >> > [1]
> > >> > https://lists.oasis-open.org/archives/virtio-comment/202310/msg00
> > >> > 24
> > >> > 0.h
> > >> > tml [2]
> > >> > https://lists.oasis-open.org/archives/virtio-comment/202310/msg00
> > >> > 24
> > >> > 2.h
> > >> > tml
> > >>
> > >> I still have some open questions from <>
> > >> (first and last paragraph.)
> > >
> > > Above link is not accessible to me. â
> >
> > That's not a link, but a message id... many mail clients support
> > searching by it, and you can also get it from lore:
> >
> > /">https://lore.kernel.org/all/[email protected]/
> >
> > > I addressed your comments/questions in v4.
> > > Can you please check v4 if they are addressed? I rewrote as you
> > > suggested in
> > v3.
> >
> > This was for points you did not agree with. (Again, it might be
> > helpful to wait with posting a new version until discussion has
> > somewhat
> > concluded.)
> Sure, will wait next time.
> 
> Your comment was,
> =====
> This is not really clear to me just from this text, especially if you just wrote
> above that enabling or re-enabling is something different... my understanding
> would be:
> 
> - if neither dynamic vqs nor queue reset are supported or negotiated,
>   the only way to enable a vq is before DRIVER_OK, during setup
> - both of these features rely on the transport supporting enabling
>   individual queues (either a queue that has not been enabled before, or
>   a queue that has been reset)
> - the transport is supposed to use the same mechanism for either
> 
> Did I get it right? If so, I think we should make it a bit more clear.
> =====
> 
> Above is clarified in below wording without complicating the queue_reset here.
> 
> Does that look ok to you?
> 
> +When VIRTIO_F_RING_DYNAMIC is not negotiated, the driver enables the
> +virtqueues during the device initialization sequence, i.e. after the
> +device sets the FEATURES_OK status bit and before the driver setting the
> DRIVER_OK status bit.
> +
> +When VIRTIO_F_RING_DYNAMIC is negotiated, the driver is not required to
> +enable every virtqueue it wants to use before setting the DRIVER_OK
> +status bit; the driver can choose to enable a virtqueue even after the
> +driver has set the DRIVER_OK status bit. The virtqueue enable mechanism is
> transport specific.
> +

Can you please respond?
We must make progress with this and the flow filters which are depending on this for a long time now.