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

[Alvaro Karsz <alvaro.karsz@solid-run.com>]

> > 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?
> 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)

Opps, I missed a word in here, it should have been:
Then device receives VIRTIO_NET_CTRL_NOTF_COAL_VQ_SET with vqn = 0,
vq0 changes the parameters accordingly (all RX vqs EXCEPT FOR vq0
still use the previous parameters)