Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 4 Apr 2022 11:12:54 -0400
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "chuck.lever@oracle.com" <chuck.lever@oracle.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Question about RDMA server...
Message-ID: <20220404151254.GA17195@fieldses.org>
References: <82662b7190f26fb304eb0ab1bb04279072439d4e.camel@hammerspace.com>
 <1114899D-BBF5-4CB1-9126-E4E652ACAAB6@oracle.com>
 <5DCBD9EB-7721-48FC-9EBD-58B7DF05A704@oracle.com>
 <8af942181abb39cd7ce8fe91be9c4c2f8c9f2c56.camel@hammerspace.com>
 <2E4807E4-5086-4F15-B790-8D952B394FE5@oracle.com>
 <974fa169124661c2ce5ed549d499837435cc7b4c.camel@hammerspace.com>
 <E7FD566B-0570-4D14-9936-5C737B619E0B@oracle.com>
 <b9b98ad9b21f228566a5ebd643198c669c9f3408.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b9b98ad9b21f228566a5ebd643198c669c9f3408.camel@hammerspace.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From:   bfields@fieldses.org (J. Bruce Fields)
Precedence: bulk

On Thu, Mar 31, 2022 at 08:08:59PM +0000, Trond Myklebust wrote:
> On Thu, 2022-03-31 at 18:53 +0000, Chuck Lever III wrote:
> > It's plausible that a deferred request could be replayed, but I don't
> > understand the deferral mechanism enough to know whether the rctxt
> > would be released before the deferred request could be handled. It
> > doesn't look like it would, but I could misunderstand something.
> > 
> > There's a longstanding testing gap here: None of my test workloads
> > appear to force a request deferral. I don't recall Bruce having
> > such a test either.
> > 
> > It would be nice if we had something that could force the use of the
> > deferral path, like a command line option for mountd that would cause
> > it to sleep for several seconds before responding to an upcall. It
> > might also be done with the kernel's fault injector.
> > 
> 
> You just need some mechanism that causes svc_get_next_xprt() to set
> rqstp->rq_chandle.thread_wait to the value '0'.

Yeah, no idea what's going on here, but a way to force the deferral case
sounds like a great idea that'd come in handy some day if not this time.

(Can you hack it by, say, killing mountd, flushing the caches (exportfs
-f), then waiting a few seconds to restart mountd?)

--b.