Re: [virtio-comment] Re: [PATCH v2] virtio-net: support the virtqueue coalescing moderation

[Heng Qi <hengqi@linux.alibaba.com>]

å 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-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/