[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation
> 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. 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]