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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox