On 6/19/17 3:41 PM, Matt Benjamin wrote:
it's not about memory, this is the problem we're trying to avoid
but, referring for context to our verbal discussion earlier today, your
suggestion to hybridize the existing output side (which depends on blocking
sockets) and an async input side using recv() seems work at least exploring; I
assume you are proposing to use recv() with MSG_DONTWAIT?
Yes. Linux does support MSG_DONTWAIT, and it should be possible to try
the recv() writev() hybrid approach. At least there's one Oracle
article that says it works....
The underlying problem is EPOLL reaallly isn't a good design. What we
need for speed is callbacks that tell us that the read/write is done,
not signals that there might be more data pending -- which cause us to
do more system calls to find out. System calls are the problem.
kqueue is a much better design. We should try to get kqueue support in
the Linux kernel. That would aid portability, too.
But what I'm doing right now is backing out my previous attempt. Even
after dumping the mass code, awful lot of hooks to undo....
My thought now is it's better to get the big changes in, then work on
TCP I-O re-write separately (as I was doing for UDP and RDMA). Quick
and dirty shims, but only temporarily.
While I'm thinking about it, why does Ganesha call svc_reg()? AFAICT,
that's just filling in a tree that is never used anymore.
Can I remove that code in Ganesha? It's a pain to maintain in ntirpc.
------------------------------------------------------------------------------
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
