From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-comment@lists.oasis-open.org,
Cornelia Huck <cohuck@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>, Greg Kurz <groug@kaod.org>,
Dominique Martinet <asmadeus@codewreck.org>,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [virtio-comment] [PATCH v3 1/4] Add VIRTIO_RING_F_INDIRECT_SIZE
Date: Mon, 21 Mar 2022 10:23:07 +0100 [thread overview]
Message-ID: <1758197.u6jAxYQQ6s@silver> (raw)
In-Reply-To: <20220320171750-mutt-send-email-mst@kernel.org>
On Sonntag, 20. März 2022 22:52:16 CET Michael S. Tsirkin wrote:
> On Sun, Mar 20, 2022 at 06:43:53PM +0100, Christian Schoenebeck wrote:
> > To be honest, I don't feel like discussing precise wordings at this point
> > when you are questioning the proposal on design level already.
> >
> > Maybe you make some more thorough thoughts on what you actually want this
> > to be on design level before continueing to argue about precise
> > terminology, which you are not using either BTW when you articulating
> > your criticism.
> >
> > Or even better: come up with your own proposol with the precise wording
> > you
> > feel appropriate.
>
> OK let's go back and agree on what we are trying to achieve. The github
> issue and the cover letter imply that while indirect descriptors would
> normally allow huge tables, we artificially limit them to queue size,
> and you want to be able to relax that.
Correct, that's my motivation for all of this.
> Fair enough.
>
> However, I feel trying to talk about indirect descriptor is too narrow a
> use-case, simply because the issue is not indirect at all. Why do we
> limit number of segments? I think it's really because of backend
> limitations. And indirect is only used by the frontend. So limiting
> that is really going about it wrong.
I am only aware about current implementation situation in QEMU and Linux
kernel. As for those two: yes, it is not a limitation on Linux kernel side,
but on QEMU side.
As for other implementations: no idea.
> So block for example has seg_max already. What should happen
> if that exceeds queue size is not defined.
>
> So maybe we can generalize that making it device independent?
> The litmus paper for this is the block and scsi devices,
> we should be able to use the new feature as a super-set.
>
> Before we discuss solutions, did I formulate the problem correctly?
Keep in mind that I never worked on virtio code or virtio spec before. I just
started to review virtio implementation of QEMU and Linux kernel and the
virtio spec in November, specifically in context of 9p. I definitely don't
know all the other virtioo device classes out there.
In other words: I can't help you on fitting this appropriately into a superset
picture.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2022-03-21 9:23 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-16 13:44 [PATCH v3 0/4] Add VIRTIO_RING_F_INDIRECT_SIZE and queue_indirect_size Christian Schoenebeck
2022-03-16 13:47 ` [PATCH v3 1/4] Add VIRTIO_RING_F_INDIRECT_SIZE Christian Schoenebeck
2022-03-17 13:40 ` [virtio-comment] " Cornelia Huck
2022-03-18 10:45 ` Christian Schoenebeck
2022-03-18 16:03 ` [virtio-comment] " Cornelia Huck
2022-03-19 9:33 ` [virtio-comment] " Michael S. Tsirkin
2022-03-19 12:00 ` Christian Schoenebeck
2022-03-20 12:31 ` Michael S. Tsirkin
2022-03-20 13:32 ` Christian Schoenebeck
2022-03-20 13:55 ` Michael S. Tsirkin
2022-03-20 15:17 ` Christian Schoenebeck
2022-03-20 16:06 ` Michael S. Tsirkin
2022-03-20 16:07 ` Michael S. Tsirkin
2022-03-20 17:43 ` Christian Schoenebeck
2022-03-20 21:52 ` Michael S. Tsirkin
2022-03-21 9:23 ` Christian Schoenebeck [this message]
2022-03-21 22:13 ` Michael S. Tsirkin
2022-03-23 10:20 ` Christian Schoenebeck
2022-03-23 12:35 ` Michael S. Tsirkin
2022-03-24 9:16 ` Christian Schoenebeck
2022-03-24 10:36 ` Michael S. Tsirkin
2022-03-24 11:11 ` Christian Schoenebeck
2022-03-24 11:16 ` Michael S. Tsirkin
2022-03-24 11:52 ` Christian Schoenebeck
2022-03-16 13:50 ` [PATCH v3 2/4] Add PCI configuration field "queue_indirect_size" Christian Schoenebeck
2022-03-16 14:41 ` [virtio-comment] " Christian Schoenebeck
2022-03-16 13:52 ` [PATCH v3 3/4] Add MMIO configuration register "QueueIndirectNum" Christian Schoenebeck
2022-03-16 13:55 ` [PATCH v3 4/4] Add CCW configuration field "indirect_num" Christian Schoenebeck
2022-03-17 14:12 ` [virtio-comment] " Cornelia Huck
2022-03-18 11:02 ` Christian Schoenebeck
2022-03-18 16:06 ` Halil Pasic
2022-03-19 10:12 ` Christian Schoenebeck
2022-03-21 16:36 ` Cornelia Huck
2022-03-22 1:56 ` Halil Pasic
2022-03-22 9:57 ` Cornelia Huck
2022-03-22 11:21 ` Halil Pasic
2022-03-18 16:10 ` Cornelia Huck
2022-03-19 10:23 ` Christian Schoenebeck
2022-03-21 16:25 ` Cornelia Huck
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=1758197.u6jAxYQQ6s@silver \
--to=qemu_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=cohuck@redhat.com \
--cc=groug@kaod.org \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.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.