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

Jason Wang
2024-06-25T07:53:50Z

On Sat, Jun 22, 2024 at 7:46 AM Si-Wei Liu <si-wei.liu@oracle.com> wrote:
>
>
>
> On 6/20/2024 8:24 PM, Heng Qi wrote:
> > On Thu, 20 Jun 2024 18:21:03 -0700, "Si-Wei Liu" <si-wei.liu@oracle.com> wrote:
> >>
> >> On 6/20/2024 12:40 AM, Heng Qi wrote:
> >>> On Mon, 17 Jun 2024 16:31:25 -0700, "Si-Wei Liu" <si-wei.liu@oracle.com> wrote:
> >>>> 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...
> >>> Instead, the performance of the virtual machine and the driver depends heavily
> >>> on how the device is implemented, just as we have proposed various ways to
> >>> offload the data queue in the device to the hardware. The reason why most
> >>> devices use software to simulate ctrlq instead of using hardware offload is
> >>> that the driver has no requirements for the performance of ctrlq before, that is,
> >>> the device implementation is responsible for and meets the driver's performance
> >>> requirements.
> >> I am not sure I follow the arguments of ctrlq being s/w or h/w, I
> >> thought that it was for the debate why we need coalescing on hardware
> >> offload device in the first place, instead of reusing event index or
> >> similar s/w based notification suppression. I don't doubt the value of
> >> coalescing, but how's it relevant to the default value disposition?
> >> Generally the default config disposition is not considered to be part of
> >> device implementation, especially when it comes to the situation where
> >> device can't easily figure out the specific workload to occur in the
> >> guest, and there's no perfect single default value that could meet every
> >> single performance metric across the board. This is a typical tuning
> >> knob left up to the user to adjust, why the device or driver needs to
> >> set or load the initial value? The driver just needs to start with
> >> certain value, be it 0 or non-zero, which guest user can override at any
> >> point of time, depending on his/her need, and that's it! I guess I still
> >> don't understand your user case here, why device / driver default is of
> >> such importance.
> > I've explained that, and I understand your argument is why default value is needed,
> > and users should be able to adjust them, right?
> Sounds about right. You'll soon realize that there's no perfect default
> that could work with everyone - in that it's just a static value to
> begin with, no matter whatever initial value the device comes up with,
> one user or another will come over to you and complain that what is
> loaded from the device doesn't match the workload they have, so those
> users are still expected to adjust manually tweaking for their own. As
> long as it's a tunable that guest user can control and override anytime,
> I don't feel it too much different what initial config the device would
> start with.

Think hard of these, I think there's probably no conflict between the
points of each.

Generally, it's very hard to have a default value for virtio-net moderation as

1) various implementations of virtio-net
2) various setups of virtio-net (from virtual to physical, from 1G to 100G)
3) various kind of workloads

But it doesn't mean the device can not have something by default which
the vendor thinks it works well for in most cases. And anyhow the
value could be overridden by the driver if it wants (e.g several Linux
networking drivers will try to set a good default moderation value
during probe).

Thanks