> From: Michael S. Tsirkin <m...@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 <m...@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.

> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Reply via email to