From: Cornelia Huck <cohuck@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: virtio-comment@lists.oasis-open.org,
Stefan Hajnoczi <stefanha@redhat.com>, Greg Kurz <groug@kaod.org>
Subject: [virtio-comment] Re: [PATCH 2/2] Add common configuration field "queue_indirect_size"
Date: Mon, 03 Jan 2022 14:21:13 +0100 [thread overview]
Message-ID: <87ilv13qgm.fsf@redhat.com> (raw)
In-Reply-To: <1920878.uA8gqIOdmR@silver>
On Wed, Dec 29 2021, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> On Donnerstag, 23. Dezember 2021 12:03:50 CET Cornelia Huck wrote:
>> On Wed, Dec 15 2021, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
>> > On Dienstag, 14. Dezember 2021 18:20:28 CET Cornelia Huck wrote:
>> >> Also, this is only for split ring; does packed ring need any updates?
>> >
>> > I have not reviewed the packed ring as much as I did the split ring, so I
>> > could not say reliably all the parts that shall be updated for the packed
>> > ring. There are some obvious parts like:
>> >
>> > 2.7.5 Scatter-Gather Support
>> >
>> > "The device limits the number of descriptors in a list through a
>> > transport-
>> > specific and/or device-specific value. If not limited, the maximum number
>> > of descriptors in a list is the virt queue size."
>> >
>> > However the question is, would anybody want large descriptor chains with
>> > the packaged ring in the first place? If I understand it correctly, the
>> > benefits of the packed ring over the split ring only manifest for devices
>> > that interchange a very large number of rather small bulk data (e.g.
>> > network devices), no?
>>
>> If we think that the feature does not make sense for packed ring, they
>> should probably conflict with each other. Otherwise, I think we need at
>> least a statement that the higher limit does not take effect for packed
>> ring, or touch all the places where it would be relevant.
>>
>> What do others think?
>
> It would indeed be very useful if other people express their opinion about
> this issue (packed ring scenario) as well before I continue on this issue.
>
> Probably the fact that my patches never made it through to the list were not
> necessarily supporting this. Should I contact somebody regarding this ML
> issue? Do members of the other ML also read this virtio-comment list?
Yes, this situation is very unsatisfactory :( (I have contacted the
people running this list, but there have not yet been any fixes...)
Not sure which other lists would be appropriate to cc: -- maybe
virtualization@lists.linux-foundation.org, but that one also suffers
from DKIM issues :(
>
> I tried to compensate the current situation by updating the corresponding
> issue description on Github in a very defailed and verbose way:
> https://github.com/oasis-tcs/virtio-spec/issues/122
Thanks. Hopefully me quoting this makes it more visible (I tried to
quote more than I usually would in my other replies already...)
Just to feature it more prominently for people who collapse quotes:
https://github.com/oasis-tcs/virtio-spec/issues/122
>
> If nobody replies early January, I would suggest to continue by ignoring the
> packed ring. Because if somebody wants this for packed ring in future, this
> can still be added to the specs without breaking things, because this feature
> is negotiated per queue, not for the entire device.
The problem is that we need to specify what is supposed to happen if
packed ring *and* this feature are negotiated. If we do not want to add
statements for the packed ring case, my suggestion would be
- make packed ring and this feature mutually exclusive
- add a new feature bit that works with packed ring later, if we think
it is useful
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/
next prev parent reply other threads:[~2022-01-03 13:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-14 15:13 [PATCH 0/2] Add VIRTIO_RING_F_INDIRECT_SIZE and queue_indirect_size Christian Schoenebeck
2021-12-14 15:13 ` [PATCH 1/2] Add VIRTIO_RING_F_INDIRECT_SIZE Christian Schoenebeck
2021-12-14 16:59 ` [virtio-comment] " Cornelia Huck
2021-12-14 18:28 ` Christian Schoenebeck
2021-12-23 10:54 ` Cornelia Huck
2022-01-24 13:08 ` Stefan Hajnoczi
2022-01-24 13:14 ` [virtio-comment] " Cornelia Huck
2022-01-24 14:24 ` Christian Schoenebeck
2021-12-14 15:13 ` [PATCH 2/2] Add common configuration field "queue_indirect_size" Christian Schoenebeck
2021-12-14 17:20 ` [virtio-comment] " Cornelia Huck
2021-12-15 13:59 ` Christian Schoenebeck
2021-12-23 11:03 ` [virtio-comment] " Cornelia Huck
2021-12-29 14:16 ` Christian Schoenebeck
2022-01-03 13:21 ` Cornelia Huck [this message]
2022-01-05 13:52 ` Christian Schoenebeck
2022-01-24 13:39 ` [virtio-comment] " Stefan Hajnoczi
2022-01-24 14:31 ` Christian Schoenebeck
2022-01-24 16:41 ` Stefan Hajnoczi
2022-01-25 19:05 ` Christian Schoenebeck
2022-01-26 10:01 ` Stefan Hajnoczi
2022-01-24 13:53 ` Stefan Hajnoczi
2022-02-19 16:36 ` Christian Schoenebeck
2022-02-21 10:33 ` Stefan Hajnoczi
2022-02-21 13:28 ` Christian Schoenebeck
2022-01-24 13:54 ` [PATCH 0/2] Add VIRTIO_RING_F_INDIRECT_SIZE and queue_indirect_size Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilv13qgm.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=groug@kaod.org \
--cc=qemu_oss@crudebyte.com \
--cc=stefanha@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox