[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-comment] Re: VIRTIO_RING_F_INDIRECT_SIZE status
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]