Re: [virtio-comment] Re: VIRTIO_RING_F_INDIRECT_SIZE status

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Tuesday, March 7, 2023 1:40:24 PM CET Christian Schoenebeck wrote:
> On Monday, March 6, 2023 10:50:53 PM CET Michael S. Tsirkin wrote:
> > On Mon, Mar 06, 2023 at 03:46:01PM -0500, Stefan Hajnoczi wrote:
> > > On Mon, Mar 06, 2023 at 12:41:25PM -0500, Michael S. Tsirkin wrote:
> > > > On Mon, Mar 06, 2023 at 04:00:37PM +0100, Christian Schoenebeck wrote:
> [...]
> > > > > Anyhow, as this now gets broader scope, that also means the suggested flag
> > > > > VIRTIO_RING_F_INDIRECT_SIZE needs to be renamed. VIRTIO_RING_F_BUFFER_SIZE?
> > > > > 
> > > > > Best regards,
> > > > > Christian Schoenebeck
> > > > 
> > > > 
> > > > Hmm that's unclear in that it might be in bytes too.
> > > > Given blk and scsi call these "segments" how about
> > > > VIRTIO_RING_F_SEG_MAX?
> > > 
> > > The VIRTIO equivalent of a "segment" is an "element".
> > 
> > Hmm true:
> > 	A buffer consists of zero or more device-readable physically-contiguous
> > 	elements followed by zero or more physically-contiguous
> > 	device-writable elements (each buffer has at least one element).
> > 
> > However we then need to clean this up, since
> > 
> > - At least in one place we say
> > 
> > indirect elements to mean indirect descriptors.
> > 
> > - we also say "queue elements" to mean "avail/desc/used"
> > - We also say "descriptor elements" - not 100% sure it's the same.
> > 
> > so we need to clean this up a bit first and maybe add
> > text about indirect descriptors not counting as elements.
> 
> With VIRTIO_RING_F_BUFFER_SIZE I actually had in mind that this limit was tied
> to per buffer/message (i.e. in contrast to a limit that would apply to the
> entire queue). But you are right, the name could mislead to the interpretation
> as if it was in bytes.
> 
> How about VIRTIO_RING_F_MAX_BUF_ELEMENTS?

Ping?

Michael, another thing: what was the rationale for your suggestion to exclude
the indirect descriptor itself from this limit?

While I agree that it makes sense to broaden the scope to the total amount of
all descriptors per buffer (as I wasn't aware before that it is indeed
permitted to mix chained direct and indirect descriptors in a split queue
buffer, and given that QEMU's implementation for instance just allocates them
on the stack), however I currently don't see why it would make sense to
exclude the indirect descriptor itself, as it makes things more complicated?
Did you have something specific in mind for that exclusion?

Best regards,
Christian Schoenebeck