> > 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....
Hmm, we could definitely clean this up, it would be good to actually remove it and anything that is really necessary be thread local variables. The worker_index could become a general thread index and be a thread local variable (it really is useful for debug logging so please don't anyone get any bright ideas about removing it...). I'm sure there's a better way to handle the hostaddr part (there was also some talk about client manager being a performance downer). We do need to know the hostaddr across the stack for various reasons, but again, we should find a cleaner way to handle it that copying it into worker_data. The other fields in worker_data are specific to the fridge and queuing and should be separated anyway probably, and hopefully you are cleaning up how all that works... We actually should move ALL the request params into req_ctx, it would make for simpler function processing and it's much easier to add/remove params that way. Frank ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
