Re: [virtio-comment] Re: VIRTIO_RING_F_INDIRECT_SIZE status

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

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.

-- 
MST


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/