From: Jeff Layton <jlayton@kernel.org>
To: Andrew Klaassen <andrew.klaassen@boatrocker.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Trying to reduce NFSv4 timeouts to a few seconds on an established connection
Date: Tue, 28 Feb 2023 08:23:49 -0500 [thread overview]
Message-ID: <45e2e7f05a13abab777b3b0868744cdbfc623f2d.camel@kernel.org> (raw)
In-Reply-To: <YQBPR01MB10724998CA29C5AFF7E6B391E86AF9@YQBPR01MB10724.CANPRD01.PROD.OUTLOOK.COM>
On Mon, 2023-02-27 at 14:48 +0000, Andrew Klaassen wrote:
> > From: Andrew Klaassen <andrew.klaassen@boatrocker.com>
> > Sent: Monday, February 6, 2023 12:19 PM
> >
> > > From: Andrew Klaassen <andrew.klaassen@boatrocker.com>
> > > Sent: Monday, February 6, 2023 10:28 AM
> > >
> >
> > > [snipping for readability; hope that's okay]
> > >
> > > - I'm allocating memory. I assume that means I should free it
> > > somewhere.
> > > But where? In xprt_destroy(), which appears to do cleanup? Or in
> > > xprt_destroy_cb(), which is called from xprt_destroy() and which
> > > frees
> > > xprt-
> > > > servername? Or somewhere else completely?
> > > - If I free the allocated memory, will that cause any problems in
> > > the
> > > cases where no timeout is passed in via the args and the static
> > > const
> > > struct xs_tcp_default_timeout is assigned to xprt->timeout?
> > > - If freeing the static const struct default will cause a
> > > problem,
> > > what should I do instead? Allocate and memcpy even when assigning
> > > the
> > > default? And would that mean doing the same thing for all the
> > > other
> > > transports that are setting timeouts (local, udp, tcp, and
> > > bc_tcp)?
> >
> > [snipping more]
>
> Here's the patch in what I hope is its final form. I'm planning to
> test it on a couple of hundred nodes over the next month or two.
>
> Since I'm completely new to this, what would be the chances of
> actually getting this patch in the kernel?
>
> Thanks.
>
> Andrew
>
Excellent work! I'll be interested to hear how the testing goes!
This patch still needs a bit of work. I'd consider this a proof-of-
concept. You are at least demonstrating the problem with this patch (and
a possible solution).
Conceptually, it's not 100% clear to me that we want the exact same
timeout on the RPC call and the xprt. We might, but working with
interlocking timeouts can bring in emergent behavioral changes and I
haven't thought through these.
> From caa3308a3bcf39eb95d9b59e63bd96361e98305e Mon Sep 17 00:00:00 2001
> From: Andrew Klaassen <andrew.klaassen@boatrocker.com>
> Date: Fri, 10 Feb 2023 10:37:57 -0500
> Subject: [PATCH] Sun RPC: Use passed-in timeouts if available instead
> of
> always using defaults.
>
This needs a real patch description. Describe the problem you were
having, and how this patch changes things to address it. Make sure you
add a Signed-off-by line too.
When you resend, send it to the the nfs client maintainers (Trond and
Anna) using git-format-patch and git-send-email, and cc linux-nfs list.
I think your MUA might have mangled the patch a bit. Please look over
Documentation/process/submitting-patches.rst in the kernel source tree
too.
> ---
> include/linux/sunrpc/xprt.h | 3 +++
> net/sunrpc/clnt.c | 1 +
> net/sunrpc/xprt.c | 21 +++++++++++++++++++++
> net/sunrpc/xprtsock.c | 22 +++++++++++++++++++---
> 4 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
> index b9f59aabee53..ca7be090cf83 100644
> --- a/include/linux/sunrpc/xprt.h
> +++ b/include/linux/sunrpc/xprt.h
> @@ -333,6 +333,7 @@ struct xprt_create {
> struct svc_xprt *bc_xprt; /* NFSv4.1
> backchannel */
> struct rpc_xprt_switch *bc_xps;
> unsigned int flags;
> + const struct rpc_timeout *timeout; /* timeout parms */
> };
>
> struct xprt_class {
> @@ -373,6 +374,8 @@
> void xprt_release_xprt_cong(struct rpc_xprt *xprt, struct rpc_task *task);
> void xprt_release(struct rpc_task *task);
> struct rpc_xprt * xprt_get(struct rpc_xprt *xprt);
> void xprt_put(struct rpc_xprt *xprt);
> +struct rpc_timeout *xprt_alloc_timeout(const struct rpc_timeout
> *timeo,
> + const struct rpc_timeout
> *default_timeo);
> struct rpc_xprt * xprt_alloc(struct net *net, size_t size,
> unsigned int num_prealloc,
> unsigned int max_req);
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index 0b0b9f1eed46..1350c1f489f7 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -532,6 +532,7 @@ struct rpc_clnt *rpc_create(struct rpc_create_args
> *args)
> .addrlen = args->addrsize,
> .servername = args->servername,
> .bc_xprt = args->bc_xprt,
> + .timeout = args->timeout,
> };
> char servername[48];
> struct rpc_clnt *clnt;
> diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
> index ab453ede54f0..0bb800c90976 100644
> --- a/net/sunrpc/xprt.c
> +++ b/net/sunrpc/xprt.c
> @@ -1801,6 +1801,26 @@ static void xprt_free_id(struct rpc_xprt *xprt)
> ida_free(&rpc_xprt_ids, xprt->id);
> }
>
> +struct rpc_timeout *xprt_alloc_timeout(const struct rpc_timeout
> *timeo,
> + const struct rpc_timeout
> *default_timeo)
> +{
> + struct rpc_timeout *timeout;
> +
> + timeout = kzalloc(sizeof(*timeout), GFP_KERNEL);
> + if (!timeout)
> + return ERR_PTR(-ENOMEM);
> + if (timeo)
> + memcpy(timeout, timeo, sizeof(struct rpc_timeout));
> + else
> + memcpy(timeout, default_timeo, sizeof(struct
> rpc_timeout));
I don't think you need an allocation here. struct rpc_timeout is quite
small and it only contains a bunch of integers. I think it'd be better
to just embed this in struct rpc_xprt instead.
> + return timeout;
> +}
> +
> +static void xprt_free_timeout(struct rpc_xprt *xprt)
> +{
> + kfree(xprt->timeout);
> +}
> +
> struct rpc_xprt *xprt_alloc(struct net *net, size_t size,
> unsigned int num_prealloc,
> unsigned int max_alloc)
> @@ -1837,6 +1857,7 @@ EXPORT_SYMBOL_GPL(xprt_alloc);
>
> void xprt_free(struct rpc_xprt *xprt)
> {
> + xprt_free_timeout(xprt);
> put_net_track(xprt->xprt_net, &xprt->ns_tracker);
> xprt_free_all_slots(xprt);
> xprt_free_id(xprt);
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index aaa5b2741b79..13703f8e0ef1 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -2924,7 +2924,12 @@ static struct rpc_xprt *xs_setup_udp(struct
> xprt_create *args)
>
> xprt->ops = &xs_udp_ops;
>
> - xprt->timeout = &xs_udp_default_timeout;
> + xprt->timeout = xprt_alloc_timeout(args->timeout,
> &xs_udp_default_timeout);
> + if (IS_ERR(xprt->timeout))
> + {
Kernel coding style has the brackets on the same line as the "if"
statement. You should run your next iteration through checkpatch.pl.
> + ret = ERR_CAST(xprt->timeout);
> + goto out_err;
> + }
>
> INIT_WORK(&transport->recv_worker,
> xs_udp_data_receive_workfn);
> INIT_WORK(&transport->error_worker, xs_error_handle);
> @@ -3003,7 +3008,13 @@ static struct rpc_xprt *xs_setup_tcp(struct
> xprt_create *args)
> xprt->idle_timeout = XS_IDLE_DISC_TO;
>
> xprt->ops = &xs_tcp_ops;
> - xprt->timeout = &xs_tcp_default_timeout;
> +
> + xprt->timeout = xprt_alloc_timeout(args->timeout,
> &xs_tcp_default_timeout);
> + if (IS_ERR(xprt->timeout))
> + {
> + ret = ERR_CAST(xprt->timeout);
> + goto out_err;
> + }
>
> xprt->max_reconnect_timeout = xprt->timeout->to_maxval;
> xprt->connect_timeout = xprt->timeout->to_initval *
> @@ -3071,7 +3082,12 @@ static struct rpc_xprt *xs_setup_bc_tcp(struct
> xprt_create *args)
> xprt->prot = IPPROTO_TCP;
> xprt->xprt_class = &xs_bc_tcp_transport;
> xprt->max_payload = RPC_MAX_FRAGMENT_SIZE;
> - xprt->timeout = &xs_tcp_default_timeout;
> + xprt->timeout = xprt_alloc_timeout(args->timeout,
> &xs_tcp_default_timeout);
> + if (IS_ERR(xprt->timeout))
> + {
> + ret = ERR_CAST(xprt->timeout);
> + goto out_err;
> + }
>
> /* backchannel */
> xprt_set_bound(xprt);
> --
> 2.39.1
>
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2023-02-28 13:23 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 16:31 Trying to reduce NFSv4 timeouts to a few seconds on an established connection Andrew Klaassen
2023-01-23 16:35 ` Chuck Lever III
2023-01-23 16:41 ` Andrew Klaassen
2023-01-26 15:31 ` Andrew Klaassen
2023-01-26 22:08 ` Andrew Klaassen
2023-01-27 13:33 ` Jeff Layton
2023-01-30 19:33 ` Andrew Klaassen
2023-01-30 19:55 ` Jeff Layton
2023-01-30 20:03 ` Andrew Klaassen
2023-01-30 20:31 ` Jeff Layton
2023-01-30 22:11 ` Zombie / Orphan open files Andrew J. Romero
2023-01-31 0:10 ` Chuck Lever III
2023-01-31 13:27 ` Jeff Layton
2023-01-31 14:42 ` Andrew J. Romero
2023-01-31 15:24 ` Jeff Layton
2023-01-31 15:31 ` Chuck Lever III
2023-01-31 16:34 ` Chuck Lever III
2023-01-31 16:59 ` Andrew J. Romero
2023-01-31 18:05 ` Chuck Lever III
2023-01-31 18:33 ` Andrew J. Romero
2023-01-31 18:51 ` Chuck Lever III
2023-01-31 19:32 ` Andrew J. Romero
2023-01-31 19:08 ` Olga Kornievskaia
2023-01-31 19:31 ` Olga Kornievskaia
2023-01-31 19:54 ` Andrew J. Romero
2023-01-31 22:14 ` Olga Kornievskaia
2023-01-31 22:26 ` Andrew J. Romero
2023-01-31 22:47 ` Olga Kornievskaia
2023-01-31 23:08 ` Andrew J. Romero
2023-02-01 14:28 ` Olga Kornievskaia
[not found] ` <SA1PR09MB755217D2B3E29E9486D4796FA7D19@SA1PR09MB7552.namprd09.prod.outlook.com>
[not found] ` <CAN-5tyGaX=Go+kwrM33K2EaY41sXmf4v1+2JO8MhbDuGTGG7zA@mail.gmail.com>
[not found] ` <SA1PR09MB755277F59EB463643BEBDD77A7D69@SA1PR09MB7552.namprd09.prod.outlook.com>
2023-02-02 0:53 ` Olga Kornievskaia
2023-01-31 22:28 ` Jeff Layton
2023-01-31 18:13 ` Jeff Layton
2023-01-31 16:26 ` Olga Kornievskaia
2023-01-31 17:44 ` Andrew J. Romero
2023-01-31 18:18 ` Frank Filz
2023-01-31 19:19 ` Olga Kornievskaia
2023-01-31 21:31 ` Frank Filz
2023-01-31 21:46 ` Andrew J. Romero
2023-02-02 18:16 ` Trying to reduce NFSv4 timeouts to a few seconds on an established connection Andrew Klaassen
2023-02-06 15:27 ` Andrew Klaassen
2023-02-06 17:18 ` Andrew Klaassen
2023-02-27 14:48 ` Andrew Klaassen
2023-02-28 13:23 ` Jeff Layton [this message]
2023-03-02 15:25 ` Andrew Klaassen
2023-03-02 18:47 ` Andrew Klaassen
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=45e2e7f05a13abab777b3b0868744cdbfc623f2d.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=andrew.klaassen@boatrocker.com \
--cc=linux-nfs@vger.kernel.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