On Wed, 2019-07-17 at 14:12 -0400, Chuck Lever wrote: > > On Jul 17, 2019, at 1:19 PM, Trond Myklebust < > > trondmy@xxxxxxxxxxxxxxx> wrote: > > > > On Wed, 2019-07-17 at 09:55 -0400, Chuck Lever wrote: > > > Hi Trond- > > > > > > > On Jul 16, 2019, at 4:01 PM, Trond Myklebust <trondmy@xxxxxxxxx > > > > > > > > > wrote: > > > > > > > > Add a per-transport maximum limit in the socket case, and add > > > > helpers to allow the NFSv4 code to discover that limit. > > > > > > For RDMA, the number of credits is permitted to change during the > > > life > > > of the connection, so this is not a fixed limit for such > > > transports. > > > > This is defining a maximum value, which is used for backchannel > > session > > slot negotiation. > > > > > And, AFAICT, it's not necessary to know the transport's limit. > > > The > > > lesser of the NFS backchannel and RPC/RDMA reverse credit limit > > > will > > > be used. > > > > The server needs to know how many requests it can send in parallel > > on > > the back channel. If it sends too many, which it can and will do on > > TCP, then we currently break the connection, and so callbacks end > > up > > being dropped or missed altogether. > > IIUC, RPC/RDMA has a fixed maximum constant. Would you like a patch > at > some point that advertises that constant via ->bc_num_slots ? > Sure. Thanks! -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
