> > 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
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 co
Hi Bill,
This isn't the current work plan/design as I understand it, so I'd appreciate it
if you walk through your blocker with us here.
Also "I" is me, as I could have told you.
Thank you.
Matt
- "William Allen Simpson" wrote:
> I've been struggling with the fridge threads. For NFS/RDM
I've been struggling with the fridge threads. For NFS/RDMA,
once we are running a work thread, we really don't want to
hand off to another work thread during processing in
thr_decode_rpc_request() -- adds considerable latency.
Panasas also reports latency and stalls in VFS::PanFS.
Currently, the
