RE: [virtio] [PATCH REQUIREMENTS v2 4/7] net-features: Add notification coalescing requirements

[Parav Pandit <parav@nvidia.com>]

> From: Stefan Hajnoczi <stefanha@redhat.com>
> 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.