Re: [virtio] [OASIS Issue Tracker] Created: (VIRTIO-15) Simplify indirect descriptors

[Rusty Russell <rusty@au1.ibm.com>]

OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org> writes:
> Simplify indirect descriptors
> -----------------------------
>
>                  Key: VIRTIO-15
>                  URL: http://tools.oasis-open.org/issues/browse/VIRTIO-15
>              Project: OASIS Virtual I/O Device (VIRTIO) TC
>           Issue Type: Improvement
>             Reporter: Rusty Russell
>
>
> The current definition of VIRTIO_DESC_F_INDIRECT is that it stacks: you can set that bit and VIRTIO_DESC_F_NEXT and after processing the (only single level!) of indirect descriptors, the device then processes the next descriptor as normal (which may also be indirect).  No implementation I am aware of generates such multi-part indirect descriptors, but they could be useful if we allow huge indirect descriptors as proposed.
>
> Perhaps we should make the bit chain, so if any descriptor has that set, we start traversing that descriptor as a new table, and never return.  This is simpler to implement, and backwards compatible as well.
>

That would look something like this:

commit b6ebc21dba82817a2b238a073f30e15d4cc741a2
Author: Rusty Russell <rusty@au1.ibm.com>
Date:   Tue Aug 20 16:08:07 2013 +0930

    Simplify indirect descriptors
    
    As per http://tools.oasis-open.org/issues/browse/VIRTIO-15.
    
    Signed-off-by: Rusty Russell <rusty@au1.ibm.com>

diff --git a/virtio-v1.0-wd01-part1-specification.txt b/virtio-v1.0-wd01-part1-specification.txt
index d8302cb..8fc96b2 100644
--- a/virtio-v1.0-wd01-part1-specification.txt
+++ b/virtio-v1.0-wd01-part1-specification.txt
@@ -274,9 +274,9 @@ Some devices benefit by concurrently dispatching a large number
 of large requests. The VIRTIO_RING_F_INDIRECT_DESC feature can be 
 used to allow this (see FIXME: Reserved Feature Bits). To increase 
 ring capacity it is possible to store a table of indirect 
-descriptors anywhere in memory, and insert a descriptor in main 
-virtqueue (with flags&VRING_DESC_F_INDIRECT on) that refers to memory buffer 
-containing this indirect descriptor table; fields addr and len 
+descriptors anywhere in memory, and insert a descriptor in 
+virtqueue descriptor table with the VRING_DESC_F_INDIRECT flag set that refers 
+those descriptors; fields addr and len 
 refer to the indirect table address and length in bytes, 
 respectively. The indirect table layout structure looks like this 
 (len is the length of the descriptor that refers to this table, 
@@ -290,10 +290,9 @@ which is a variable, so this code won't compile):
 The first indirect descriptor is located at start of the indirect 
 descriptor table (index 0), additional indirect descriptors are 
 chained by next field. An indirect descriptor without next field 
-(with flags&VRING_DESC_F_NEXT off) signals the end of the indirect descriptor 
-table, and transfers control back to the main virtqueue. An 
-indirect descriptor can not refer to another indirect descriptor 
-table (flags&VRING_DESC_F_INDIRECT must be off). A single indirect descriptor 
+(ie. without the VRING_DESC_F_NEXT flag set) signals the end of the descriptor 
+chain. An indirect descriptor with the VRING_DESC_F_INDIRECT flag set
+refers to the next set of indirect descriptors. A single indirect descriptor 
 table can include both read-only and write-only descriptors; 
 write-only flag (flags&VRING_DESC_F_WRITE) in the descriptor that refers to it 
 is ignored.