virtio — archive

[Stefan Hajnoczi <parav@nvidia.com>]

On Mon, Jul 03, 2023 at 02:44:07AM +0300, Parav Pandit wrote: > Add virtio net device notification coalescing improvements requirements. > > Signed-off-by: Parav Pandit <parav@nvidia.com> > --- > changelog: > v0->v1: > - updated the description > --- > net-workstream/features-1.4.md | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/net-workstream/features-1.4.md b/net-workstream/features-1.4.md > index 3e8b5a4..a34556c 100644 > --- a/net-workstream/features-1.4.md > +++ b/net-workstream/features-1.4.md > @@ -8,6 +8,7 @@ together is desired while updating the virtio net interface. > # 2. Summary > 1. Device counters visible to the driver > 2. Low latency tx and rx virtqueues for PCI transport > +3. Virtqueue notification coalescing re-arming support > > # 3. Requirements > ## 3.1 Device counters > @@ -157,3 +158,14 @@ struct vnet_rx_completion { > which can be recycled by the driver when the packets from the completed > page is fully consumed. > 8. The device should be able to consume multiple pages for a receive GSO stream. > + > +## 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. > +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? 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? Can this new mechanism be generic for any kind of virtqueue, not just virtio-net rx/tx? > -- > 2.26.2 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >