在 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
