Re: VIRTIO_RING_F_INDIRECT_SIZE status

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

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?