On Wed, 2019-01-02 at 13:17 -0500, Chuck Lever wrote: > > On Dec 31, 2018, at 2:21 PM, Trond Myklebust < > > trondmy@xxxxxxxxxxxxxxx> wrote: > > > > On Mon, 2018-12-31 at 19:18 +0000, Trond Myklebust wrote: > > > On Mon, 2018-12-31 at 14:09 -0500, Chuck Lever wrote: > > > > > On Dec 31, 2018, at 1:59 PM, Trond Myklebust < > > > > > trondmy@xxxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > The test for rpcauth_xmit_need_reencode() happens when we call > > > xprt_request_transmit() to actually put the RPC call on the wire. > > > The > > > enqueue order should not be able to defeat that test. > > > > > > Hmm... Is it perhaps the test for req->rq_bytes_sent that is > > > failing > > > because this is a retransmission after a disconnect/reconnect > > > that > > > didn't trigger a re-encode? > > > > Actually, it might be worth a try to move the test for > > rpcauth_xmit_need_reencode() outside the enclosing test for req- > > > rq_bytes_sent as that is just a minor optimisation. > > Perhaps that's the case for TCP, but RPCs sent via xprtrdma never set > req->rq_bytes_sent to a non-zero value. The body of the "if" > statement > is always executed for those RPCs. > Then the question is what is defeating the call to rpcauth_xmit_need_reencode() in xprt_request_transmit() and causing it not to trigger in the misordered cases? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
