On Thu, Mar 21, 2024 at 4:57 PM Jonah Palmer <jonah.pal...@oracle.com> wrote:
>
> Define the InOrderVQElement structure for the VIRTIO_F_IN_ORDER
> transport feature implementation.
>
> The InOrderVQElement structure is used to encapsulate out-of-order
> VirtQueueElement data that was processed by the host. This data
> includes:
> - The processed VirtQueueElement (elem)
> - Length of data (len)
> - VirtQueueElement array index (idx)
> - Number of processed VirtQueueElements (count)
>
> InOrderVQElements will be stored in a buffering mechanism until an
> order can be achieved.
>
> Signed-off-by: Jonah Palmer <jonah.pal...@oracle.com>
> ---
> include/hw/virtio/virtio.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index b3c74a1bca..c8aa435a5e 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -77,6 +77,13 @@ typedef struct VirtQueueElement
> struct iovec *out_sg;
> } VirtQueueElement;
>
> +typedef struct InOrderVQElement {
> + const VirtQueueElement *elem;
Some subsystems allocate space for extra elements after
VirtQueueElement, like VirtIOBlockReq. You can request virtqueue_pop
to allocate this extra space by its second argument. Would it work for
this?
> + unsigned int len;
> + unsigned int idx;
> + unsigned int count;
Now I don't get why these fields cannot be obtained from elem->(len,
index, ndescs) ?
> +} InOrderVQElement;
> +
> #define VIRTIO_QUEUE_MAX 1024
>
> #define VIRTIO_NO_VECTOR 0xffff
> --
> 2.39.3
>
