All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>, NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: Rick Macklem <rmacklem@uoguelph.ca>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 4/7] SUNRPC: Mark connection-oriented transports on svc_xprt
Date: Fri, 28 Aug 2026 14:19:48 -0400	[thread overview]
Message-ID: <798a28cffecc0c16e30841f8a5edaba2a718986b.camel@kernel.org> (raw)
In-Reply-To: <20260828-duplicate-reply-cache-v2-4-25069e660a7b@kernel.org>

On Fri, 2026-08-28 at 12:17 -0400, Chuck Lever wrote:
> A TCP or RDMA svc_xprt carries one client's request stream, delivered
> reliably and in order, so a later request on it indicates that earlier
> replies reached the client. A UDP svc_xprt is shared by every peer and
> offers no such signal.
> 
> Add an XPT_ORDERED flag, set by the TCP and RDMA init paths and clear
> for UDP, so the NFSD duplicate reply cache can confine implied-ACK
> eviction to transports where the signal holds.
> 
> The flag has a cost on svcrdma. handle_connect_req() zeroes the remote
> port in the DRC key so a cached reply survives a reconnect, and
> implied-ACK eviction can retire such an entry while the original
> connection is still up. TCP gives up the same thing whenever a client
> re-binds its reserved port, so this follows from the eviction policy
> rather than from RDMA.
> 
> Signed-off-by: Chuck Lever <cel@kernel.org>
> ---
>  include/linux/sunrpc/svc_xprt.h          | 1 +
>  include/trace/events/sunrpc.h            | 1 +
>  net/sunrpc/svcsock.c                     | 1 +
>  net/sunrpc/xprtrdma/svc_rdma_transport.c | 1 +
>  4 files changed, 4 insertions(+)
> 
> diff --git a/include/linux/sunrpc/svc_xprt.h b/include/linux/sunrpc/svc_xprt.h
> index 53ed073640a6..ebab18e403b2 100644
> --- a/include/linux/sunrpc/svc_xprt.h
> +++ b/include/linux/sunrpc/svc_xprt.h
> @@ -99,6 +99,7 @@ enum {
>  	XPT_LOCAL,		/* connection from loopback interface */
>  	XPT_KILL_TEMP,		/* call xpo_kill_temp_xprt before closing */
>  	XPT_CONG_CTRL,		/* has congestion control */
> +	XPT_ORDERED,		/* connection-oriented, in-order delivery */
>  	XPT_HANDSHAKE,		/* xprt requests a handshake */
>  	XPT_TLS_SESSION,	/* transport-layer security established */
>  	XPT_PEER_AUTH,		/* peer has been authenticated */
> diff --git a/include/trace/events/sunrpc.h b/include/trace/events/sunrpc.h
> index 180346e520ff..2154fbe69945 100644
> --- a/include/trace/events/sunrpc.h
> +++ b/include/trace/events/sunrpc.h
> @@ -1931,6 +1931,7 @@ TRACE_EVENT(svc_stats_latency,
>  	svc_xprt_flag(LOCAL)						\
>  	svc_xprt_flag(KILL_TEMP)					\
>  	svc_xprt_flag(CONG_CTRL)					\
> +	svc_xprt_flag(ORDERED)						\
>  	svc_xprt_flag(HANDSHAKE)					\
>  	svc_xprt_flag(TLS_SESSION)					\
>  	svc_xprt_flag(PEER_AUTH)					\
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 840bec53e1ee..97a592ddeb48 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -1486,6 +1486,7 @@ static bool svc_tcp_init(struct svc_sock *svsk, struct svc_serv *serv)
>  		return false;
>  	set_bit(XPT_CACHE_AUTH, &svsk->sk_xprt.xpt_flags);
>  	set_bit(XPT_CONG_CTRL, &svsk->sk_xprt.xpt_flags);
> +	set_bit(XPT_ORDERED, &svsk->sk_xprt.xpt_flags);
>  	if (sk->sk_state == TCP_LISTEN) {
>  		strcpy(svsk->sk_xprt.xpt_remotebuf, "listener");
>  		set_bit(XPT_LISTENER, &svsk->sk_xprt.xpt_flags);
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index fabdfd891a41..5d39fce231a3 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -218,6 +218,7 @@ static struct svcxprt_rdma *svc_rdma_create_xprt(struct svc_serv *serv,
>  	 * transports are suitable here.
>  	 */
>  	set_bit(XPT_CONG_CTRL, &cma_xprt->sc_xprt.xpt_flags);
> +	set_bit(XPT_ORDERED, &cma_xprt->sc_xprt.xpt_flags);
>  
>  	return cma_xprt;
>  }

It would be helpful to see how this new flag will be used other than in
the tracepoint. Maybe this patch should be folded into the following
one?
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2026-08-28 18:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28 16:17 [PATCH v2 0/7] Implied-ACK eviction for NFSD's duplicate reply cache Chuck Lever
2026-08-28 16:17 ` [PATCH v2 1/7] SUNRPC: Assign a unique identifier to each svc_xprt Chuck Lever
2026-08-28 18:37   ` Jeff Layton
2026-08-28 16:17 ` [PATCH v2 2/7] NFSD: Track transport in DRC entries Chuck Lever
2026-08-28 16:17 ` [PATCH v2 3/7] SUNRPC: Record last-request timestamp on svc_xprt Chuck Lever
2026-08-28 16:17 ` [PATCH v2 4/7] SUNRPC: Mark connection-oriented transports " Chuck Lever
2026-08-28 18:19   ` Jeff Layton [this message]
2026-08-28 16:17 ` [PATCH v2 5/7] NFSD: Evict completed DRC entries via implied ACK Chuck Lever
2026-08-28 18:38   ` Jeff Layton
2026-08-28 18:59     ` Chuck Lever
2026-08-28 19:15       ` Jeff Layton
2026-08-28 20:37         ` Chuck Lever
2026-08-28 16:17 ` [PATCH v2 6/7] NFSD: Add tracepoints for DRC entry eviction Chuck Lever
2026-08-28 16:17 ` [PATCH v2 7/7] NFSD: Record DRC population in lookup tracepoints Chuck Lever

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=798a28cffecc0c16e30841f8a5edaba2a718986b.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=cel@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=rmacklem@uoguelph.ca \
    --cc=tom@talpey.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.