OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [virtio-comment] Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation


> From: Alvaro Karsz <alvaro.karsz@solid-run.com>
> Sent: Saturday, February 11, 2023 5:19 AM

> > Therefore, if our specification tends to be practical, we can add
> > Parav's proposal, and if our specification tends to be more general,
> > then hand over the constraints to the driver implementation. what do
> > you think?
> 
> Hi,
> I understand your and Parav's point, and that this is needed for netdim.
> I just think that the spec should not dictate this, and this should be
> implementation specific.
> What if a OS with a different adaptive functionality wants to support these
> features?
> 
> This is just my opinion though.

We donât dictate it in the spec. in the spec just defines 
a. the behavior for device should do when both are configured
One way to say, it doesnât try to configure both.
Driver should disable one and switch to other.
Simple for driver, device implementation and spec as this is more common scenario.

Other way to say, spec wants the door to remain open for mixed mode here.
b. In this case the priority is defined as (last configured for a given object). So device is clear how to implement mixed mode.

#a is well known case. #b is more flexible.
Both spec definitions look good to me, we just got to describe it.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]