Re: [PATCH v5] virtio-net: clarify coalescing parameters settings

Si-Wei Liu
2024-06-17T23:31:41Z

On 6/16/2024 7:27 PM, Heng Qi wrote:
> On Thu, 13 Jun 2024 02:13:50 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>> On Tue, Jun 11, 2024 at 05:43:18PM +0000, Parav Pandit wrote:
>>>
>>>> From: Michael S. Tsirkin <mst@redhat.com>
>>>> Sent: Tuesday, June 11, 2024 10:00 PM
>>>
>>>> How we can we make progress with
>>>> the realease but sure we don't make backwards compat a pain?
>>>>
>>>> Ideas?
>>>>
>>> There is no functional break with this relaxation.
>>> Device set some non-zero defaults and driver didn't modify them....
>>> Anything broken? Unlikely.
Generally it's inappropriate to leave this decision making to the device
for what would be the best / most performant default config, as the
device is generally considered agnostic to the guest load... Unless the
device is specially hard wired to some fixed guest setup that users
couldn't change, it doesn't seem logical that the device could derive
the best or most performant config on driver's behalf. What if the guest
wants best latency for its load but the device just blindlessly guess
the guest might prefer throughput friendly that it miserably uses
latency impacting non-zero default? Could this device side change for
the default config regress boot time performance (which may need best
latency over throughput)?

>>> And device/driver has better performance, is that a problem? Unlikely.
>>>
Even for rare case with a hard wired setup, the way to tackle the very
problem using device's default is still quite questionable. Usually the
mgmt software or network config utility should be equipped with some
default value if need be. And we know the guest has the best position to
impose the best / most performant config for its own load. What is the
issue or use case that this initial config couldn't be applied by the
guest mgmt software ahead but has to resort to the device to load some
default (which is odd and irrelevant to any guest load), before the
interface is brought up for operation i.e. performing I/O?

> Sorry, my vacation just ended.
>
>> Yes, it is possible. Driver can cache values it sets
>> and never query device with get.
> Don't we already have a lot of behaviors to drive queries from devices?
> RSS context, device stats.
>
>> Before anything is set, driver will report incorrect values.
> Devices that are widely supported and supported by good practices should have
> any initialization value. Just reporting 0 is incorrect value. Although the
> spec now says so.
I don't have an aligned view here, sorry. As I recall having 0 as the
default is just to keep device started in a state where coalescing is
disabled, so it's backward compatible and consistent with a
non-coalescing supporting driver - such that it won't yield surprising
effect (for e.g. regressed latency) inadvertently after user's getting
driver software upgraded. Unlike the other virtio-net features that
could 100% improve performance in all aspect, this coalescing feature is
more of a performance tuning knob that may improve performance metrics
(such as cpu usage or throughput) of one dimension while demoting the
others (such as latency, jitter or connection rate) from the equation.
That said, there's not a single and fixed set of default config that
device could supply which is able to satisfy all kind of guest load.
Rather than rely on the device to offer a matching default for driver
(which I think it's technically wrong), I'd lean to having guest
software or network utility to apply the initial config for the guest,
where they should have best knowledge for the specific guest workload
than what device could do.

>
>> What will break as a result? Hard to predict.
>>
>>
>> Given the patch is big, I am inclined to say it just should use
>> a feature bit.
>>
> This doesn't seem to break anything in my opinion, we just told the device that
> now you can set more values.
Another thing this could break is live migration between devices with
varied default. How do you make sure the guest doesn't rely on some
default from the source device, while on the destination it just doesn't
get the same default coalescing value? To get rid of this side effect
the guest would still need to apply the initial config for its own,
anyway... Which eventually would render this proposal with arbitrary
default rather pointless.

Thanks,
-Siwei
>
> Using new feature bits does not seem necessary.
>
> Thanks.
>
>> --
>> MST
>>