OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[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]