> From: Heng Qi <[email protected]> > Sent: Tuesday, February 7, 2023 9:36 PM > > > 在 2023/2/8 上午10:20, Parav Pandit 写道: > >> From: Xuan Zhuo <[email protected]> > >> Sent: Tuesday, February 7, 2023 8:46 PM > >> > >> On Tue, 7 Feb 2023 09:06:19 -0500, "Michael S. Tsirkin" > >> <[email protected]> > >> 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 <[email protected]> > >>>> Reviewed-by: Xuan Zhuo <[email protected]> > >>> 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
