From: Chuck Lever III <chuck.lever@oracle.com>
To: Steve French <smfrench@gmail.com>
Cc: David Howells <dhowells@redhat.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"jlayton@kernel.org" <jlayton@kernel.org>
Subject: Re: [LSF/MM/BPF TOPIC] Netfs support library
Date: Wed, 9 Mar 2022 16:17:39 +0000 [thread overview]
Message-ID: <C9AC7BE7-E72A-47FC-AF70-0134AE9AAE66@oracle.com> (raw)
In-Reply-To: <CAH2r5muY-bh6H5SSmAF37TAHiZCSa8-UbMKk2=HQEmxyK1vdsQ@mail.gmail.com>
> On Mar 4, 2022, at 3:06 PM, Steve French <smfrench@gmail.com> wrote:
>
> On Tue, Feb 1, 2022 at 10:51 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>>
>>> On Jan 31, 2022, at 4:06 PM, David Howells <dhowells@redhat.com> wrote:
>>>
>>> I've been working on a library (in fs/netfs/) to provide network filesystem
>>> support services, with help particularly from Jeff Layton. The idea is to
>>> move the common features of the VM interface, including request splitting,
>>> operation retrying, local caching, content encryption, bounce buffering and
>>> compression into one place so that various filesystems can share it.
>>
>> IIUC this suite of functions is beneficial mainly to clients,
>> is that correct? I'd like to be clear about that, this is not
>> an objection to the topic.
>>
>> I'm interested in discussing how folios might work for the
>> NFS _server_, perhaps as a separate or adjunct conversation.
>
> That is an interesting point. Would like to also discuss whether it
> could help ksmbd,
Agreed that ksmbd might also benefit.
Of primary interest is how read and write operations move
their payloads from the network transports directly to the
page cache. For the most efficient operation, the transport
layer would need to set up a receive buffer using page
cache pages instead of what is currently done: receive
buffers are constructed from anonymous pages and then these
pages replace the file's page cache pages.
RDMA transports make this straightforward, at least from
the transport layer's perspective.
> and would like to continue discussion of netfs improvements - especially am
> interested in how we can improve throttling when network (or server)
> is congested
> (or as network adapters are added/removed and additional bandwidth is
> available).
As I understand it, the protocols themselves have flow control
built in. At least SMB Direct and NFS/RDMA do, and NFSv4
sessions provides a similar mechanism for transports that don't
have a native flow control mechanism. I'm not sufficiently
familiar with SMB to know how flow control works there.
However, each of these mechanisms all have their own specific
rules. I'm not sure if there's much that can be extracted into
a common library, but can you be more specific about what is
needed?
--
Chuck Lever
next prev parent reply other threads:[~2022-03-09 16:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-31 21:06 [LSF/MM/BPF TOPIC] Netfs support library David Howells
2022-02-01 2:16 ` Chuck Lever III
2022-02-01 2:32 ` Matthew Wilcox
2022-02-01 15:35 ` Chuck Lever III
2022-03-04 20:06 ` Steve French
2022-03-09 16:17 ` Chuck Lever III [this message]
2022-03-09 21:25 ` Steve French
2022-02-01 3:57 ` Gao Xiang
2022-02-01 13:24 ` Christian Brauner
2022-02-03 20:59 ` Steve French
2022-03-01 9:45 ` David Howells
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=C9AC7BE7-E72A-47FC-AF70-0134AE9AAE66@oracle.com \
--to=chuck.lever@oracle.com \
--cc=dhowells@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=smfrench@gmail.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 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 NNTP newsgroup(s).