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

["Michael S. Tsirkin" <mst@redhat.com>]

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?
I also think we need to have a way to reset to that
default value. Maybe setting #packets to 0 should do that?


-- 
MST