From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: David Howells <dhowells@redhat.com>
Cc: dhowells@redhat.com, Eric Van Hensbergen <ericvh@kernel.org>,
Dominique Martinet <asmadeus@codewreck.org>,
Latchesar Ionkov <lucho@ionkov.net>,
Matthew Wilcox <willy@infradead.org>,
Jeff Layton <jlayton@kernel.org>,
Christian Brauner <christian@brauner.io>,
netfs@lists.linux.dev, v9fs@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] 9p: Further netfslib-related changes
Date: Mon, 29 Jan 2024 21:53:09 +0100 [thread overview]
Message-ID: <5747464.0Q8nNhgPvr@silver> (raw)
In-Reply-To: <1400271.1706538135@warthog.procyon.org.uk>
On Monday, January 29, 2024 3:22:15 PM CET David Howells wrote:
> Christian Schoenebeck <linux_oss@crudebyte.com> wrote:
>
> > > (1) Enable large folio support for 9p. This is handled entirely by
> > > netfslib and is already supported in afs. I wonder if we should limit
> > > the maximum folio size to 1MiB to match the maximum I/O size in the 9p
> > > protocol.
> >
> > The limit depends on user's 'msize' 9p client option and on the 9p transport
> > implementation. The hard limit with virtio transport for instance is currently
> > just 500k (patches for virtio 4MB limit fetching dust unfortunately).
>
> Okay. Is that 500KiB or 512Kib?
'msize' is currently hard limited by virtio transport to exactly 512000. For
rdma and fd transports it's both exactly 1MiB. For xen transport it should be
exactly 524288 (could be lowered though depending on configured xen ring
size). You find the individual transports to fill the field 'maxsize'
accordingly (in net/9p/trans_*.c).
So that's the maximum message size. Then the individual 9p message header
size needs to be subtracted. For Twrite request that's -23, for Rread
response that's -11.
> > Would you see an advantage to limit folio size? I mean p9_client_read() etc.
> > are automatically limiting the read/write chunk size accordingly.
>
> For reads not so much, but for writes it would mean that a dirty folio is
> either entirely written or entirely failed. I don't know how important this
> would be for the 9p usecases.
>
> David
>
>
prev parent reply other threads:[~2024-01-29 20:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 11:54 [RFC PATCH 0/3] 9p: Further netfslib-related changes David Howells
2024-01-29 11:54 ` [RFC PATCH 1/3] 9p: Enable large folio support David Howells
2024-01-29 11:54 ` [RFC PATCH 2/3] 9p: Make better use of netfslib's writethrough caching David Howells
2024-01-29 11:54 ` [RFC PATCH 3/3] 9p: Always update remote_i_size in stat2inode David Howells
2024-01-29 14:14 ` [RFC PATCH 0/3] 9p: Further netfslib-related changes Christian Schoenebeck
2024-01-29 14:22 ` David Howells
2024-01-29 20:53 ` Christian Schoenebeck [this message]
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=5747464.0Q8nNhgPvr@silver \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=ericvh@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=netfs@lists.linux.dev \
--cc=v9fs@lists.linux.dev \
--cc=willy@infradead.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).