Re: Intention to work on GSoC project

[daleyoung4242@gmail.com]

Hi,

On Monday, March 25, 2024 21:20:32 CST Sahil wrote:
> Q1.
> Section 2.7.4 of the virtio spec [3] states that in an available descriptor,
> the "Element Length" stores the length of the buffer element. In the next
> few lines, it also states that the "Element Length" is reserved for used
> descriptors and is ignored by drivers. This sounds a little contradictory
> given that drivers write available desciptors in the descriptor ring.

When VIRTQ_DESC_F_WRITE is set, the device will use "Element Length" to 
specify the length it writes. When VIRTQ_DESC_F_WRITE is not set, which means 
the buffer is read-only for the device, "Element Length" will not be changed by 
the device, so drivers just ignore it.

> Q2.
> In the Red Hat article, just below the first listing ("Memory layout of a
> packed virtqueue descriptor"), there's the following line referring to the
> buffer id in
> "virtq_desc":
> > This time, the id field is not an index for the device to look for the
> > buffer: it is an opaque value for it, only has meaning for the driver.
> 
> But the device returns the buffer id when it writes the used descriptor to
> the descriptor ring. The "only has meaning for the driver" part has got me
> a little confused. Which buffer id is this that the device returns? Is it
> related to the buffer id in the available descriptor?

In my understanding, buffer id is the element that avail descriptor marks to 
identify when adding descriptors to table. Device will returns the buffer id in 
the processed descriptor or the last descriptor in a chain, and write it to 
the descriptor that used idx refers to (first one in the chain). Then used idx 
increments.

The Packed Virtqueue blog [1] is helpful, but some details in the examples are 
making me confused. 

Q1.
In the last step of the two-entries descriptor table example, it says both 
buffers #0 and #1 are available for the device. I understand descriptor[0] is 
available and descriptor[1] is not, but there is no ID #0 now. So does the 
device got buffer #0 by notification beforehand? If so, does it mean buffer #0 
will be lost when notifications are disabled?

Q2.
If I'm right, the buffer id of the first descriptor in chain will be overwritten 
with the last id. But in Figure: Using another descriptor chain in the last 
step of the chain example, the buffer id of the first descriptor (4th in the 
table) in second chain doesn't change to 1. Is this a typo or I'm wrong?

Thanks,
Dale Young

[1] https://www.redhat.com/en/blog/packed-virtqueue-how-reduce-overhead-virtio