From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alvaro Karsz <alvaro.karsz@solid-run.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
Parav Pandit <parav@nvidia.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
Jason Wang <jasowang@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Subject: [virtio-dev] Re: [virtio-comment] Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation
Date: Sun, 12 Feb 2023 16:08:36 -0500 [thread overview]
Message-ID: <20230212160656-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJs=3_CpUtc36kxQURiZhpDe4YYasWDQYoMpdfKaEq5LE0v3Bw@mail.gmail.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.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-02-12 21:08 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 7:01 [virtio-comment] [PATCH v2] virtio-net: support the virtqueue coalescing moderation Heng Qi
2023-02-10 8:38 ` [virtio-comment] " Michael S. Tsirkin
2023-02-10 9:30 ` [virtio-dev] " Alvaro Karsz
2023-02-10 9:39 ` [virtio-comment] " Michael S. Tsirkin
2023-02-10 9:53 ` Heng Qi
2023-02-10 10:29 ` [virtio-dev] " Michael S. Tsirkin
2023-02-10 11:19 ` [virtio-comment] " Heng Qi
2023-02-12 20:47 ` Michael S. Tsirkin
2023-02-13 2:36 ` Heng Qi
2023-02-13 8:17 ` Michael S. Tsirkin
2023-02-10 9:22 ` [virtio-comment] " Alvaro Karsz
2023-02-10 9:38 ` Michael S. Tsirkin
2023-02-10 10:00 ` Heng Qi
2023-02-10 10:16 ` [virtio-dev] " Alvaro Karsz
2023-02-10 11:24 ` Heng Qi
2023-02-10 10:31 ` Michael S. Tsirkin
2023-02-10 11:29 ` Heng Qi
2023-02-10 9:57 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-10 19:36 ` [virtio-comment] " Parav Pandit
2023-02-11 2:01 ` [virtio-comment] Re: [virtio-dev] " Heng Qi
2023-02-11 8:45 ` [virtio-comment] " Alvaro Karsz
2023-02-11 9:42 ` Alvaro Karsz
2023-02-11 10:00 ` Heng Qi
2023-02-11 10:18 ` Alvaro Karsz
2023-02-11 13:57 ` Parav Pandit
2023-02-11 15:46 ` Alvaro Karsz
2023-02-11 15:57 ` [virtio-dev] " Parav Pandit
2023-02-11 16:13 ` Alvaro Karsz
2023-02-11 16:22 ` Parav Pandit
2023-02-13 3:13 ` Heng Qi
2023-02-12 20:23 ` [virtio-dev] " Michael S. Tsirkin
2023-02-12 20:53 ` Alvaro Karsz
2023-02-12 21:08 ` Michael S. Tsirkin [this message]
2023-02-11 13:47 ` [virtio-comment] " Parav Pandit
2023-02-12 9:35 ` [virtio-comment] " Michael S. Tsirkin
2023-02-13 3:17 ` Heng Qi
2023-02-13 2:52 ` Heng Qi
2023-02-12 20:43 ` [virtio-dev] " Michael S. Tsirkin
2023-02-13 3:21 ` [virtio-comment] " Heng Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230212160656-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alvaro.karsz@solid-run.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.