From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: Alvaro Karsz <alvaro.karsz@solid-run.com>,
Heng Qi <hengqi@linux.alibaba.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-comment] Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation
Date: Sun, 12 Feb 2023 04:35:37 -0500 [thread overview]
Message-ID: <20230212043434-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB548143E73BFAD7207F60F5DFDCDF9@PH0PR12MB5481.namprd12.prod.outlook.com>
On Sat, Feb 11, 2023 at 01:47:16PM +0000, Parav Pandit wrote:
>
>
> > From: Alvaro Karsz <alvaro.karsz@solid-run.com>
> > Sent: Saturday, February 11, 2023 3:45 AM
> >
> > > Please add short description something like,
> > >
> > > When the driver prefers to use per virtqueue notifications coalescing, and if
> > queue group (transmit or receive) level notification coalescing is enabled, driver
> > SHOULD first disable device level notification coalescing.
> > > Or it should be,
> > >
> >
> > I disagree here.
> > IMO "queue group level notification coalescing" is not something to enable or
> > disable, but a shortcut to set all TX/RX queues at once.
> That short cut is the enable/disablement.
>
> > Why should the spec force a driver to "disable device level notification
> > coalescing" (I assume you mean send a
> > VIRTIO_NET_CTRL_NOTF_COAL_[T/R]X_SET command with zeros)?
> Yes. Because to have well defined behavior when sw configured both one after the another.
>
> > What if the driver sends a VIRTIO_NET_CTRL_NOTF_COAL_[T/R]X_SET
> > command, and then a single queue traffic increases? why should it zero the
> > parameters to all other queues?
> That is short transition when driver is switching over to per queue mode.
> This is fine to have short glitch.
>
> > I think that this should be discussed in the driver implementation stage, not in
> > the spec.
> >
> There should be a clear guidance on how device should behave when both per q and per device are configured.
>
> > > Virtqueue level notifications coalescing, and device level notifications can be
> > enabled together.
> > > When both of them are enabled, per virtqueue notifications coalescing take
> > priority over queue group level.
> >
> > How do you enable Virtqueue level notifications coalescing? Why are they
> > different entities?
> Using the new command that has vqn in it.
>
> > I don't think that we should have priorities, but the last command should be the
> > one that dictates the coalescing parameters.
> >
> Priority is applicable when driver has issued both the commands. Per tx/rx, and per vqn.
>
> > For example, let's look at vq0 (RX):
> > Device receives VIRTIO_NET_CTRL_NOTF_COAL_RX_SET, vq0 should change
> > the parameters accordingly (all RX vqs should do the same).
> > Then device receives VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET with vqn = 0,
> > vq0 changes the parameters accordingly (all RX vqs are still using the "old"
> > parameters) Then device receives VIRTIO_NET_CTRL_NOTF_COAL_RX_SET, vq0
> > changes the parameters accordingly (all RX vqs should do the same).
> In this example, per VQ were overridden with per device.
> Yes, so the last one is applicable, so priority of last one applies.
>
> We continue to refuse to add the mode, and hence need to supply these description of both the sequence on how device should behave.
>
> Sequence_1:
> 1. tx/rx group level
> 2. per vqn level
> When #2 is done, VQ's whose per vq level is configured, follows vqn, rest of the VQs follow #1.
>
> Sequence_2:
> 1. per vqn
> 2. tx/rx group level
> When #2 is done, group level overrides the per vqn parameters.
Since there's apparently some room for misunderstanding, I think adding these examples can't hurt.
I would also be more specific and just use specific numbers in the
example, to avoid any ambiguity.
--
MST
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2023-02-12 9:35 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 ` [virtio-dev] " Michael S. Tsirkin
2023-02-11 13:47 ` [virtio-comment] " Parav Pandit
2023-02-12 9:35 ` Michael S. Tsirkin [this message]
2023-02-13 3:17 ` [virtio-comment] " 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=20230212043434-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.