On 9/20/17 10:14 AM, Matt Benjamin wrote:
The 4.1 call/reply logic definitely did work, but whatever.
To the best of my knowledge, it still does.
The call flow is completely changed.
How so? I'm proposing changing the call flow, but at this time both
the TCP and UDP clnt_call() remain the same as before.
TCP now always prepares bi-directional flows. That code has been
there a long time, but was never used. It still waits for the
service thread to process the incoming message, then passes it back
to the waiting call thread.
UDP hasn't changed (yet). It still handles its input in the call
thread rather than in a listening service thread. That should be
part of this effort....
On Wed, Sep 20, 2017 at 10:08 AM, William Allen Simpson
<william.allen.simp...@gmail.com> wrote:
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.
As far as I know, there should be no reason to queue anything above
ntirpc, after refactoring.
It seems that we are in violent agreement.
------------------------------------------------------------------------------
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
