Re: [virtio-comment] Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation

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

On Sun, Feb 12, 2023 at 10:53:50PM +0200, Alvaro Karsz wrote:
> > I'm not sure the specific property is even a feature and not a bug.
> > One can argue e.g. that ethtool should fail with EBUSY rather
> > than being silently overwritten.
> > Thats why I feel this kind of policy is best set by driver.
> 
> When you write "set by driver", you mean that [X] the spec needs to
> define the driver behavior in this case, or that [Y] every driver
> should decide what's best?
> I'll answer to [X], if you meant [Y] the following part is not relevant.

Y.

> If we talk implementation here, I would probably implement it like that:
> 
> net_dim_start_tx:
>         set_ethtool_blocking_bool
>         save_current_coalescing_params  # Maybe?
>         clear_all_tx_coalescing_params     # NOTF_COAL_TX_SET 0
>         do_net_dim
> 
> net_dim_stop_tx:
>       restore_prev_ethtool_coalesing_params
>       clear_ethtool_blocking_bool
> 
> It's reasonable to assume that sending a ethtool set coalesce when
> netdim is operating will affect the performance.
> 
> But, windows' virtio_net driver may want to use _CTRL_NOTF_COAL_TX_SET
> in its adaptive algorithm, and may have no userspace tool to configure
> these parameters.
> If we force the driver to clear/block some commands while using
> others, we may do more harm than good in windows' case.
> 
> This is just my personal perspective.
> 
> I think that this is an important feature either way.