Hi, ----- Original Message ----- > From: "William Allen Simpson" <william.allen.simp...@gmail.com> > To: "Matt Benjamin" <mbenja...@redhat.com> > Cc: "NFS Ganesha Developers" <nfs-ganesha-devel@lists.sourceforge.net> > Sent: Monday, June 19, 2017 10:03:53 PM > Subject: Re: [Nfs-ganesha-devel] async dispatch not good > > 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.
They have latency, sure. > > kqueue is a much better design. We should try to get kqueue support in > the Linux kernel. That would aid portability, too. You're welcome to try, seems political. > > 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.... Sorry. > > 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. One of the key goals I have is read-frags-ahead/non-blocking decode. Has been at the top of the queue since our initial meetings. Seems like your recv() technique should work. > > 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. If it's no longer effective, then eventually, sure. Is it a substantial help to your work? Matt > -- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309 ------------------------------------------------------------------------------ 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
