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

Halil Pasic
2024-06-10T20:19:12Z

On Mon, 10 Jun 2024 21:35:45 +0800
Heng Qi <hengqi@linux.alibaba.com> wrote:

> On Mon, 10 Jun 2024 14:46:02 +0200, Halil Pasic <pasic@linux.ibm.com> wrote:
[..]

> > > If the device chooses a stupid
> > > maximum value, it is his choice (spec should give more devices choices instead of
> > > forcing them to choose "0" which is not the best practice). We can't talk about
> > > performance for drivers when the devices tend to choose any "stupid" designs.
> > >
> > > We need relaxe the restrictions and makes the spec more reasonable.
> > >
> >
> > Hm, I see Linux virtio-net changes have landed with v6.0 and if I read
> > those correctly the driver -- contrary to my initial expectation --
> > negotiates the feature, but does not set the parameters explicitly and
>
> How does the driver know what parameters to set?

Disclaimer: I'm not very knowledgeable when it comes to networking and
NICs. Please be patient with me.

If I understood that properly have previously stated that it is basically
a trade-off between "latency friendly" (downside: overhead and not so
throughput friendly) and "throughput friendly" (downside: not so latency
friendly). And that makes sense to me.

So I would think, the answer to the question what is the best trade-off
should also depend on the workload.

Now as far as I understand although we call the parameters max_usecs and
max_packets the notification condition is dictated by those two values. I.e.
there won't be a notification unless the compound condition is met.

When there is no traffic 0 and 0 looks like reasonable values to me: I
want the first of possibly many packets ASAP. Depending on the actual
load, maybe one could employ some sort of a heuristics to keep good
balance -- maybe based on a frequency of interrupts. Maybe DIM is
actually exactly what I have in mind.

You seem more knowledgeable on the topic. How is this usually done? How
are the optimal values correlated with device characteristics?

> The parameters should be
> exposed by each device.

I would like to better understand why. My intention is not to question
the correctness of this statement, but to gain a better understanding.

>
> > thus keeps the defaults (until userspace decides to set the parameters).
> > So it does matter whether the defaults are guaranteed to be 0 or not,
> > and if not it does matter what defaults are chosen by the device.
>
> Didn't follow this. More below.
>

Maybe my statement was wrong. So let me make a question out of it. What
entity or entities do we expect to change the parameter values, and when
or under which conditions do we expect them to change the parameter
values?

> >
> > One could even argue that those patches have been reviewed under the
> > assumption that the device needs to use 0 as the default parameter value.
>
> The default value should not be explicitly specified in the spec, because one
> size does not fit multiple devices.

This ties in to my previous question about the relationship between
device characteristics and the optimal values for max_usecs and
max_packets.

> The source of this problem is that we are
> missing fields like default_{rx, tx}_coalesicng_params that indicate the device
> capabilities. No?

I don't think so! In my understanding is that with your proposal
after a reset, the OS/driver has no problem obtaining the defaults that
indicate the device capabilities. But I would really like to better
understand that device capabilities part.

And yes another way around this would have been say:
* let us introduce those defaults fields, e.g. to the config space
* make the driver read those values as a part of the initialization
* and set those values as the initial parameters.
But frankly I see no benefit of that over what you propose here.

Regards,
Halil