OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [PATCH] virtio-pci: implement VIRTIO_F_RING_STATE


On Wed, Jul 07, 2021 at 12:34:41PM +0800, Jason Wang wrote:
> This patch is a follow up for the virtqueue state synchronization
> series to implement VIRTIO_F_RING_STATE via a dedicated capability for
> PCI transport.
> 
> With the help of the STOP status bit, the virtqueue state
> synchronization for PCI should be self contained.
> 
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  content.tex | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)

This may not be critical, but the interface reminds me of the legacy
fw_cfg interface that was slow. It was replaced by a DMA interface that
reduced the number of vmexits. fw_cfg often transferred far more data
than this interface, so the inefficiency was a bigger problem.

If there was an admin virtqueue then the state of all virtqueues could
be saved/loaded in a single request instead of requiring 2 accesses per
virtqueue.

Assuming a register access takes 1 microsecond, a device with 64
virtqueues needs 128 microseconds to save/load virtqueue state. The
actual register access time will vary depending on how the device is
implemented (VFIO, vDPA, userspace). The total time is probably going to
be acceptable, however, if we need an admin virtqueue anyway, then maybe
do this as an admin virtqueue request instead of a transport-specific
method?

Stefan

Attachment: signature.asc
Description: PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]