From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Eric Van Hensbergen <ericvh@gmail.com>,
Latchesar Ionkov <lucho@ionkov.net>,
Nikolay Kichukov <nikolay@oldum.net>
Subject: Re: [PATCH v5 00/11] remove msize limit in virtio transport
Date: Wed, 13 Jul 2022 06:13:16 +0900 [thread overview]
Message-ID: <Ys3j7KucZGdFkttA@codewreck.org> (raw)
In-Reply-To: <cover.1657636554.git.linux_oss@crudebyte.com>
Alright; anything I didn't reply to looks good to me.
Christian Schoenebeck wrote on Tue, Jul 12, 2022 at 04:35:54PM +0200:
> OVERVIEW OF PATCHES:
>
> * Patches 1..6 remove the msize limitation from the 'virtio' transport
> (i.e. the 9p 'virtio' transport itself actually supports >4MB now, tested
> successfully with an experimental QEMU version and some dirty 9p Linux
> client hacks up to msize=128MB).
I have no problem with this except for the small nitpicks I gave, but
would be tempted to delay this part for one more cycle as it's really
independant -- what do you think?
> * Patch 7 limits msize for all transports to 4 MB for now as >4MB would need
> more work on 9p client level (see commit log of patch 7 for details).
>
> * Patches 8..11 tremendously reduce unnecessarily huge 9p message sizes and
> therefore provide performance gain as well. So far, almost all 9p messages
> simply allocated message buffers exactly msize large, even for messages
> that actually just needed few bytes. So these patches make sense by
> themselves, independent of this overall series, however for this series
> even more, because the larger msize, the more this issue would have hurt
> otherwise.
time-wise we're getting close to the merge window already (probably in 2
weeks), how confident are you in this?
I can take patches 8..11 in -next now and probably find some time to
test over next weekend, are we good?
--
Dominique
next prev parent reply other threads:[~2022-07-12 21:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 14:35 [PATCH v5 00/11] remove msize limit in virtio transport Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 01/11] 9p/trans_virtio: separate allocation of scatter gather list Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 02/11] 9p/trans_virtio: turn amount of sg lists into runtime info Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 03/11] 9p/trans_virtio: introduce struct virtqueue_sg Christian Schoenebeck
2022-07-12 20:33 ` Dominique Martinet
2022-07-13 9:14 ` Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 04/11] net/9p: add trans_maxsize to struct p9_client Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 05/11] 9p/trans_virtio: support larger msize values Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 06/11] 9p/trans_virtio: resize sg lists to whatever is possible Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 07/11] net/9p: limit 'msize' to KMALLOC_MAX_SIZE for all transports Christian Schoenebeck
2022-07-12 20:38 ` Dominique Martinet
2022-07-12 14:31 ` [PATCH v5 08/11] net/9p: split message size argument into 't_size' and 'r_size' pair Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 09/11] 9p: add P9_ERRMAX for 9p2000 and 9p2000.u Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 10/11] net/9p: add p9_msg_buf_size() Christian Schoenebeck
2022-07-13 10:29 ` Dominique Martinet
2022-07-13 13:06 ` Christian Schoenebeck
2022-07-13 20:52 ` Dominique Martinet
2022-07-14 13:14 ` Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 11/11] net/9p: allocate appropriate reduced message buffers Christian Schoenebeck
2022-07-12 19:33 ` Dominique Martinet
2022-07-12 21:11 ` [V9fs-developer] " Dominique Martinet
2022-07-13 9:19 ` Christian Schoenebeck
2022-07-13 9:29 ` Christian Schoenebeck
2022-07-13 9:56 ` Dominique Martinet
2022-07-13 9:29 ` Dominique Martinet
2022-07-13 10:22 ` Christian Schoenebeck
2022-07-12 21:13 ` Dominique Martinet [this message]
2022-07-13 8:54 ` [PATCH v5 00/11] remove msize limit in virtio transport 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=Ys3j7KucZGdFkttA@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=ericvh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=nikolay@oldum.net \
--cc=v9fs-developer@lists.sourceforge.net \
/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.