Re: [virtio-comment] Re: VIRTIO_RING_F_INDIRECT_SIZE status

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Mar 13, 2023 at 02:48:23PM +0100, Christian Schoenebeck wrote:
> On Monday, March 13, 2023 2:06:00 PM CET Michael S. Tsirkin wrote:
> > On Mon, Mar 13, 2023 at 12:48:11PM +0100, Christian Schoenebeck wrote:
> > > 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
> > > 
> > 
> > It matches the requirement to limit the number of s/g elements. For
> > example, both qemu and vhost need to limit this to 1K since  they are
> > using the iov[1024] structure to pass buffers around.
> > Indirect descriptors are just a different way to link to s/g elements
> > they are not s/g elements themselves.
> 
> OK, I see, I am just wondering whether that wouldn't make phrasing this in the
> spec unnecessarily more complicated and confusing. Not that I'd care much.
> 
> And what about my latest name suggestion VIRTIO_RING_F_MAX_BUF_ELEMENTS?
> 
> Best regards,
> Christian Schoenebeck


Fine by me. What do others think?