在 2023/2/11 下午4:45, Alvaro Karsz 写道:
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.
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)?
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?
Hi, Alvaro! Thanks for your reply!
I think Parav refers more to the scene where ethool sets parameters at
the queue group level and
the scene where netdim sets parameters for a single queue. In this
scenario, netdim should really
determine the coalescing parameters of the device, and the parameters at
the queue group level set
by ethtool should be ignored (many drivers are designed this way, such
as mlx), that is, we need to give netdim the right,
because it It has the ability to dynamically adjust parameters.
(However, I think this friendly constraint is also possible in driver
implementation.)
Of course, if we consider setting coalescing parameters at the queue
group level and single queue level separately through ethtool,
then as you said, we should not set any priority for them.
Back to reality, I think the function of ethtool to set single queue
parameters may come later, which is thankless for users because of netdim.
Therefore, if our specification tends to be practical, we can add
Parav's proposal, and if our specification tends to be more general,
then hand over
the constraints to the driver implementation. what do you think?
I think that this should be discussed in the driver implementation
stage, not in the spec.
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?
I don't think that we should have priorities, but the last command
should be the one that dictates the coalescing parameters.
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).
Yes I see what you mean, thanks for the clear example. This should be
the second scenario I described above,
let's discuss how to solve it in the above reply.
Thanks! :)
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-subscr...@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscr...@lists.oasis-open.org
List help: virtio-comment-h...@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/
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
