>
From: Stefan Hajnoczi <>
> Sent: Thursday, July 20, 2023 11:19 AM > > +## 3.3 Virtqueue notification coalescing re-enable support >
> It's called "re-arming" above but "re-enable" here. Please choose one term and
> use it consistently.
> Will change to re-arming as "enablement" can be easily confused with queue_enable and reset registers of pci.
> > +0. Design goal: > > +
a. Avoid constant notification from the device even in conditions when > > +
the driver may not have acted on the previous pending notification. > > +1. When Tx and Rx virtqueue notification coalescing is enabled, and when
> such > > +
notification is reported by the device, device should be able to > > +disable > > "notification" -> "a notification" > > ", device" -> ", the device" > > > +
further notifications until the driver finish reacting to the > > + already >
> s/finish/finishes/ > > > +
generated notification. > > +2. When the driver enables the notification coalescing reporting, the > > +device > > "enables the notification coalescing reporting" -> "enables notification
> coalescing reporting" > > > +
to notify again if notification coalescing conditions are met. >
> I can't parse this sentence. Maybe "the device _has_ to notify again ..."? >
> I find this text hard to understand. Is this a mechanism where the device does
> not send further notifications on a virtqueue until the driver has re-armed
> them?
> Right. I will rephrase it.
> How does this relate to EVENT_IDX, which can be used to achieve a similar
> effect? I guess the downside to EVENT_IDX is that the device must DMA
> repeatedly in order to detect changes from driver, whereas this new re-arming
> mechanism involves a hardware register write?
> Correct. It is similar to EVENT_IDX without polling large scale unique addresses on the PCI.
> Can this new mechanism be generic for any kind of virtqueue, not just virtio-net
> rx/tx? Maybe we can. Haven't found wider usage yet for it. One needs to create a generic interface first to configure such things. It was kind of implicit requirement that I didn't write it specific to this feature. Config space was one way, but we discovered, debated and agreed that instead of config space, we should have a dma interface to exchange such info between driver and device. Its now due for many features. I suggest since receive flow filter has such requirement, we start with generic interface for it and expand to more like this one. I will revise v3 to capture your inputs further.
