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

Reply via email to