[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage
Hi Cornelia, > From: Parav Pandit <parav@nvidia.com> > Sent: Monday, October 23, 2023 8:52 PM > To: Cornelia Huck <cohuck@redhat.com>; Michael S. Tsirkin > <mst@redhat.com> > Cc: virtio-comment@lists.oasis-open.org; hengqi@linux.alibaba.com; > xuanzhuo@linux.alibaba.com; Shahaf Shuler <shahafs@nvidia.com> > Subject: RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling > virtqueue after DRIVER_OK stage > > > > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- > > open.org> On Behalf Of Cornelia Huck > > Sent: Monday, October 23, 2023 8:31 PM > > > > On Mon, Oct 23 2023, Parav Pandit <parav@nvidia.com> wrote: > > > > >> From: Cornelia Huck <cohuck@redhat.com> > > >> Sent: Monday, October 23, 2023 7:58 PM > > > > > >> On Mon, Oct 23 2023, Parav Pandit <parav@nvidia.com> wrote: > > >> > > >> >> From: virtio-comment@lists.oasis-open.org > > >> >> <virtio-comment@lists.oasis- 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 <87sf68cjn0.fsf@redhat.com> > > >> (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: > > > > 87sf68cjn0.fsf@redhat.com/">https://lore.kernel.org/all/87sf68cjn0.fsf@redhat.com/ > > > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]