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

[Heng Qi <hengqi@linux.alibaba.com>]

å 2023/3/9 äå6:30, Parav Pandit åé:
> > 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.

I think it is reasonable and will be revised in the next version.

> > > 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.

Ok.

Thanks.