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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, February 8, 2023 9:18 AM
> 
> On Wed, Feb 08, 2023 at 07:30:34PM +0800, Heng Qi wrote:
> > > I see two options.
> > > 1. Just have per VQ params. Software has the full knowledge of in which it is
> operating, and state remains at software level.
> > > This effectively achieves both the mode.
> > >
> > > 2. Have a mode cmd,
> > > Mode = (a) per device or (b) per VQ (c) disable After the mode is
> > > set, driver can set per device or per VQ.
> >
> > I find this more clear.
> >
> > Thanks.
> >
> 
> Rereading this I think I misunderstood the proposal.
> Now we are burning memory on maintaining mode, and this information is
> duplicated.
> 
It is not maintained in the pci resident memory, so it doesn't hurt.

> I'd say let's just add a new command COAL_QUEUE_SET with vqn as parameter.
> Existing commands are simply defined as a shortcut to running
> COAL_QUEUE_SET on all tx/rx queues respectively.
> 
> Latest command dictates the parameters. To disable just set everything to 0
> (btw we should make this explicit in the spec, but it can be guessed from:
> Upon reset, a device MUST initialize all coalescing parameters to 0.
> )
> 
Switching between the modes (per q vs per device) implicitly is ambiguous and it only means device may need to iterate.
This state is either better maintained in sw by always having per vq or have clearly defined mode of what device should do.

Per Q is very common even for several years old devices.
Last time I counted, there were at least 15 such devices supporting it.

So actual usage wise, I practically see that most implementations will end up with per vq mode.
I like to hear from Heng or Alvaro if they see any use of per device.