virtio — archive

[PATCH REQUIREMENTS v2 0/7] virtio net new features requirements

From: Parav Pandit <[email protected]>
To: [email protected]
Date: Sun, 23 Jul 2023 21:40:00 -0000

> From: Stefan Hajnoczi <[email protected]> > 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.