From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: v9fs-developer@lists.sourceforge.net, netdev@vger.kernel.org,
Eric Van Hensbergen <ericvh@gmail.com>,
Latchesar Ionkov <lucho@ionkov.net>, Greg Kurz <groug@kaod.org>,
Vivek Goyal <vgoyal@redhat.com>,
Nikolay Kichukov <nikolay@oldum.net>
Subject: Re: [PATCH v4 12/12] net/9p: allocate appropriate reduced message buffers
Date: Sun, 03 Apr 2022 16:00:56 +0200 [thread overview]
Message-ID: <2745077.ukKBhl4x9b@silver> (raw)
In-Reply-To: <YkmVI6pqTuMD8dVi@codewreck.org>
On Sonntag, 3. April 2022 14:37:55 CEST Dominique Martinet wrote:
> Christian Schoenebeck wrote on Sun, Apr 03, 2022 at 01:29:53PM +0200:
> > So maybe I should just exclude the 9p RDMA transport from this 9p message
> > size reduction change in v5 until somebody had a chance to test this
> > change with RDMA.
>
> Yes, I'm pretty certain it won't work so we'll want to exclude it unless
> we can extend the RDMA protocol to address buffers.
OK, agreed. It only needs a minor adjustment to this patch 12 to exclude the
RDMA transport (+2 lines or so). So no big deal.
> > On the long-term I can imagine to add RDMA transport support on QEMU 9p
> > side.
> What would you expect it to be used for?
There are several potential use cases that would come to my mind, e.g:
- Separating storage hardware from host hardware. With virtio we are
constrained to the same machine.
- Maybe also a candidate to achieve what the 9p 'synth' driver in QEMU tried
to achieve? That 'synth' driver is running in a separate process from the
QEMU process, with the goal to increase safety. However currently it is
more or less abondened as it is extremely slow, as 9p requests have to be
dispatched like:
guest -> QEMU (9p server) -> synth daemon -> QEMU (9p server) -> guest
Maybe we could rid of those costly extra hops with RDMA, not sure though.
- Maybe also an alternative to virtio on the same machine: there are also some
shortcomings in virtio that are tedious to address (see e.g. current
struggle with pure formal negotiation issues just to relax the virtio spec
regarding its "Queue Size" requirements so that we could achieve higher
message sizes). I'm also not a big fan of virtio's assumption that guest
should guess in advance host's response size.
- Maybe as transport for macOS guest support in future? Upcoming QEMU 7.0 adds
support for macOS 9p hosts, which revives the plan to add support for 9p
to macOS guests as well. The question still is what transport to use for
macOS guests then.
However I currently don't know any details inside RDMA yet, and as you already
outlined, it probably has some shortcomings that would need to be revised with
protocol changes as well.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2022-04-03 14:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 13:23 [PATCH v4 00/12] remove msize limit in virtio transport Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 12/12] net/9p: allocate appropriate reduced message buffers Christian Schoenebeck
2022-04-02 14:05 ` Dominique Martinet
2022-04-03 11:29 ` Christian Schoenebeck
2022-04-03 12:37 ` Dominique Martinet
2022-04-03 14:00 ` Christian Schoenebeck [this message]
2021-12-30 13:23 ` [PATCH v4 08/12] net/9p: limit 'msize' to KMALLOC_MAX_SIZE for all transports Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 04/12] 9p/trans_virtio: introduce struct virtqueue_sg Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 01/12] net/9p: show error message if user 'msize' cannot be satisfied Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 10/12] 9p: add P9_ERRMAX for 9p2000 and 9p2000.u Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 11/12] net/9p: add p9_msg_buf_size() Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 06/12] 9p/trans_virtio: support larger msize values Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 02/12] 9p/trans_virtio: separate allocation of scatter gather list Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 09/12] net/9p: split message size argument into 't_size' and 'r_size' pair Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 07/12] 9p/trans_virtio: resize sg lists to whatever is possible Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 05/12] net/9p: add trans_maxsize to struct p9_client Christian Schoenebeck
2021-12-30 13:23 ` [PATCH v4 03/12] 9p/trans_virtio: turn amount of sg lists into runtime info Christian Schoenebeck
2022-01-20 22:43 ` [PATCH v4 00/12] remove msize limit in virtio transport Nikolay Kichukov
2022-01-22 13:34 ` Christian Schoenebeck
2022-01-24 10:21 ` Nikolay Kichukov
2022-01-24 11:07 ` Dominique Martinet
2022-01-24 11:57 ` Christian Schoenebeck
2022-01-24 12:56 ` Dominique Martinet
2022-01-24 13:55 ` Christian Schoenebeck
2022-01-25 8:45 ` Nikolay Kichukov
2022-05-24 8:10 ` Nikolay Kichukov
2022-05-24 11:29 ` Christian Schoenebeck
2022-07-07 14:30 ` Christian Schoenebeck
[not found] ` <CAFkjPT=GAoViYd0E7CZQDq3ZjhmYT0DsBytfZXnE10JL0P8O-Q@mail.gmail.com>
2022-07-08 1:15 ` Dominique Martinet
[not found] ` <CAFkjPTngeFh=0mPVW-Yf1Sxkxp_HDNUeANndoYN3-eU9_rGLuQ@mail.gmail.com>
2022-07-08 11:18 ` Christian Schoenebeck
2022-07-08 11:40 ` Dominique Martinet
2022-07-08 13:00 ` Christian Schoenebeck
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=2745077.ukKBhl4x9b@silver \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=ericvh@gmail.com \
--cc=groug@kaod.org \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=nikolay@oldum.net \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=vgoyal@redhat.com \
/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.