Re: [virtio-comment] RE: [virtio-dev] [PATCH] virtio-net: Fix and update VIRTIO_NET_F_NOTF_COAL feature

[Alvaro Karsz <alvaro.karsz@solid-run.com>]

> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, February 8, 2023 12:39 PM
> >
> > On Wed, Feb 08, 2023 at 05:30:28PM +0000, Parav Pandit wrote:
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Tuesday, February 7, 2023 9:18 AM
> > >
> > > > > Why migration generate too many spurious interrupts?
> > > >
> > > > Because, you might want to migrate from hardware with to hardware
> > > > without coalescing features. So you just tell guest "sure I will
> > > > coalesce" but in fact send interrupts normally.
> > >
> > > For the hardware that has fake coalescing, HV wouldn't know it anyway
> > without doing pre verification.
> > > And HV may not migrate in such case for best experience.
> > > HV may choose to migrate with low accuracy as you say, which is fine.
> > >
> > > But the spec guidance for the device implementations is to promote some
> > reasonable level of accuracy.
> > > Hard to define in words here.
> > > Best effort is wide spectrum of range. :)
> > >
> > > Typically, we say in the spec as SHOULD.
> > > So, lets skip the best-effort wording and stick to SHOULD part like rest of the
> > spec.
> >
> > I think the point of best-effort is that driver must handle interrupts that arrive
> > earlier.
> Ok. so Let's put this must requirement in the driver section like the rest.

But this requirement is already written in "Driver Requirements: Used
Buffer Notification Suppression".
Handling spurious interrupts is not NOTF_COAL specific, but generic,
regardless of NOTF_COAL.
So I don't think that this should be written in the NOTF_COAL driver section.

> > This is how we used it elsewhere.
> In a quick grep I see best effort shows two matches one for rx filter and one for vlan.
> Vlan we lately know was (close) to incorrect.
>
> > What else does it include in your
> > opinion that we absolutely must exclude?
> > I feel it's a good fit for a non-conformance section which is by nature a bit
> > informal.
> >
> > For a conformance section SHOULD is indeed a good fit.
> >
> Yes, must in driver section and should in device section looks good to me too.

The whole NOTF_COAL section is about explaining when a device should
issue an interrupt and when not, so writing "The device SHOULD NOT
issue an interrupt when it's not supposed to" seems a bit redundant to
me.