Re: [virtio-comment] Re: VIRTIO_RING_F_INDIRECT_SIZE status

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

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



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/