RE: [virtio-dev] RE: [PATCH v10] virtio-net: support the virtqueue coalescing moderation

[Parav Pandit <parav@nvidia.com>]

> From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On
> Behalf Of Heng Qi
> Sent: Thursday, March 2, 2023 10:27 PM
> 
> > I remember we discussed that instead of mentioning each individual field,
> better to describe the whole structure being read-only or write-only.
> 
> Consider the following scenarios:
> 1. A read-only field of the structure virtio_net_ctrl_coal is extended for
> CTRL_NOTF_COAL_RX/TX_SET to get some extra information 
A set command cannot extend the struct virtio_net_ctrl_coal, particularly for read-only and partially for write-only.
This would mean that for the tiny number of bytes, an additional dma descriptor is to be allocated with read/write-only permissions.
It would be inefficient for the driver to do so for the SET command to have vqn as write-only, reserved as read-only, rest fields as write-only dma attributes.

As I think more, I think the whole set command fields should be read-only for device. Better to describe it this way instead of splitting individual fields.
This way driver can just do a single DMA allocation with read-only attributes for set cmd.

Get command doesnât have any choice today the way CVQ is structured to it lives with the limitation.

> > Looks good, however you have well covered in the device normative
> statements.
> > So possibly it can be removed from here.
> 
> I tend to keep this, as we have done in the past, we can have normative
> descriptions and the corresponding non-normative descriptions.
> 
Ok. but please revisit if the description can be simpler text than the normative lines.