RE: [virtio-dev] RE: [virtio-comment] [PATCH] virtio-net: support per-queue coalescing moderation

[Parav Pandit <parav@nvidia.com>]

> From: Heng Qi <hengqi@linux.alibaba.com>
> Sent: Tuesday, February 7, 2023 9:36 PM
> 
> 
> å 2023/2/8 äå10:20, Parav Pandit åé:
> >> From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >> Sent: Tuesday, February 7, 2023 8:46 PM
> >>
> >> On Tue, 7 Feb 2023 09:06:19 -0500, "Michael S. Tsirkin"
> >> <mst@redhat.com>
> >> wrote:
> >>> On Tue, Feb 07, 2023 at 07:16:34PM +0800, Heng Qi wrote:
> >>>> Currently, the coalescing profile is directly applied to all queues.
> >>>> This patch supports configuring the parameters for a specified queue.
> >>>>
> >>>> When the traffic between queues is unbalanced, for example, one
> >>>> queue is busy and another queue is idle, then it will be very
> >>>> useful to control coalescing parameters at the queue granularity.
> >>> ethtool does not support this though, does it? what's the plan?
> >>
> >> Although it can be done, I think it is difficult to let users use
> >> ethtool to modify the parameters of each queue.
> >>
> >> At present ethtool supports adaptive-rx/adaptive-tx. This is that the
> >> driver automatically adapted to the appropriate parameter. Generally,
> >> it is implemented using netdim in the driver. At this time, this interface is
> needed.
> >>
> >>>> Signed-off-by: Heng Qi <hengqi@linux.alibaba.com>
> >>>> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> >>> What I dislike about this interface is that if
> >>> VIRTIO_NET_F_PERQUEUE_NOTF_COAL is negotiated, then in the common
> >> case
> >>> of same parameters for all queues driver has to issue multiple
> >>> commands.
> >>> I can see either a special vq index (0xffff ?) or a special command
> >>> used to set it for all queues.
> >> Although the structure is very similar, in fact, adding a new command
> >> may be clearer.
> > O(N) loop is not that bad when user want to issue change it per device, as this
> is something done very often.
> 
> However, a global configuration requires sending a command for each queue,
> which makes the device suffer.
> I think the hardware might not want this.
> 
There are many commands that a hw nic device needs to service.
So I agree that for high q count, a single command is better.
However, when a device is with such high q count, the possibility of needing it as per q params is also extremely high for best perf (and variance each q might have).
So couldnât see a lot of value in doing as global param.

But yes, if it helps, a command with explicit mode to avoid ambiguity is fine to have.
Both approaches of [1] looks good to me.

[1] https://lists.oasis-open.org/archives/virtio-dev/202302/msg00088.html