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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.