Currently, when clnt_call() is invoked, that thread waits for the result to come back over the network. There are 250 or so "fridge" threads during startup for this alone.
I've already changed the rpc_ctx_xfer_replymsg() to be transport agnostic (it was clnt_vc only). And added a result XPRT_DISPATCH to both NTI-RPC and NFS-Ganesha to prepare for distinguishing CALL from REPLY dispatching. There's already a lot of mechanism in struct _rpc_call rpc_call_t handling a callback. But the nfs_rpc_submit_call() flag NFS_RPC_CALL_INLINE skipping the nfs_rpc_enqueue_req() doesn't seem to work well (or at all). Ideally, we'd never queue, and an async callback would complete the transaction. We need to discuss how to tie that together. My current expectation is that various fields of the Ganesha rpc_call_t should be merged/replaced by fields in the NTI_RPC struct svc_req so that async dispatch can handle the callback. But I don't really know the callback code as well as others, so really would like some discussion and planning. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel