On 6/8/15 3:27 PM, Matt W. Benjamin wrote:
> This isn't the current work plan/design as I understand it,
That's why I'm bringing it to the attention of everybody.
> so I'd appreciate it if you walk through your blocker with us here.
>
No blocker. Or at least I hope not. Currently (as in the code
checked in on my rdma-was branch), I'm trying to finesse
thr_decode_rpc_request() by checking for the parameter, and
calling nfs_rpc_execute() directly for RDMA (skipping the
extra worker enqueue/dequeue).
But that only almost works. nfs_rpc_execute() has a worker_data
parameter, which is passed to every gol-darned nfs_proto function:
rc = reqnfs->funcdesc->service_function(arg_nfs,
worker_data, svcreq,
res_nfs);
I've already folded the worker_data into the fridge_entry,
reducing the alloc/free cost (as they are one-to-one).
Since I have to fake this somehow, it seems to me a good time to
simplify the fridge itself. After public discussion.
I'm hoping to eliminate the worker_data parameter entirely.
Or at least make it work for NULL.
It's impractical to copy and paste duplicate and re-write every
nfs_proto function....
> Also "I" is me, as I could have told you.
>
Aha!
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
