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

Jason Wang
2024-06-25T08:14:00Z

On Tue, Jun 25, 2024 at 4:06 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Jun 25, 2024 at 03:53:33PM +0800, Jason Wang wrote:
> > 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
>
> Do we want to just burn a feature bit on this then?

It might be more safe to do that.

> I also think we need to have a way to reset to that
> default value. Maybe setting #packets to 0 should do that?

Or a dedicated command.

Thanks

>
>
> --
> MST
>