Hi Bill, Let's just talk about the rpc-ping-mt/request minimal latency.
On Wed, Feb 21, 2018 at 8:24 AM, William Allen Simpson <william.allen.simp...@gmail.com> wrote: >> >> It measures minimal request latency all the way to nfs-ganesha's, or >> the Linux kernel's, rpcnull handler--the "top" of the request handling >> stack, in the given client/server/network configuration. Scaled up, >> it can report the max such calls/s, which is a kind of best-possible >> value for iops, taking FSAL ops to have 0 latency. >> > As I've mentioned elsewhere, this should be entirely dominated by the > link speed and protocol. We should see UDP as slowest, TCP in the > middle, and RDMA as fastest. I think the point is, the "should" assumes perfect behavior from the dispatch and (minimal) request execution path within nfs-ganesha, does it not? In other words, profiling of rpc null is effectively profiling the first stage of the request pipeline, and if it's not fast, more interesting ops won't be. > > OTOH, the "max such calls/s" would be reported by using XDR_RAW, which > is currently not working. > My intended meaning, and Daniel's when he articulated the same point Friday, is that "max such calls/s" -is- meaningful for transports NFS actually supports, and those are the ones we can compare with other implementations. I think the raw transport opens up some interesting paths, but it seems like they would involve more development. 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
