Hi Bill, ----- Original Message ----- > From: "William Allen Simpson" <william.allen.simp...@gmail.com> > To: "NFS Ganesha Developers" <nfs-ganesha-devel@lists.sourceforge.net> > Sent: Thursday, March 9, 2017 2:44:29 AM > Subject: Re: [Nfs-ganesha-devel] dispatch queues > > On 3/8/17 5:34 AM, William Allen Simpson wrote: > > Ganesha currently has 2 phases of dispatch queuing: one for input and > > decoding, then another for executing/encoding output. (I've fixed the > > third queue for later sending the output, where the thread should stay > > hot as long as there's more to process.) > > > > On Monday, Matt told me we were having problems with sequential IO. > > Wishing that somebody had mentioned this to me sooner. > > > > [...] > > > After a somewhat loud discussion with Matt, we've agreed on a > different approach. This will also be useful for fully async IO > that is planned for V2.6.
Um, I don't think this statement represents either of the two internal meetings we had accurately, but ok. > > The sequential IO reports were from specific <PEOPLE>. For posterity, the feedback I've seen regarding sequential i/o was provided by upstream folks on our regular concall. nobody uses the term "customer" on this list, for obvious reasons. > > I'm going to code something more like Weighted Fair Queuing that > I've mentioned on this list back in June 2015. The only weight is > that we want any initial TCP connection to be handled as rapidly as > possible to get the standard TCP slow start moving. > > Are there other priorities that we should handle? > > Otherwise, we really need a more even handed approach across large > numbers of clients, keeping each client's requests in strict order, > even though some of them could be "faster" than others. The fair > queuing should also help prevent traffic spikes. > > I think I can have something coded by next week. I'd already done > some preliminary work in 2015. But the time constraint means this > will be pretty bare bones for V2.5. Well, as I think we've all agreed, nothing like this is going into 2.5. Anything that DOES make it to the nfs-ganesha upstream is going to need to be well motivated, well measured, and matured. > > To really do a good job, we need some kind of FSAL feedback API. > I'm going to ask the Gluster folks for some help on designing it, so > that we have a good use case and testing infrastructure. But we'll > post the design iterations here in the same fashion as an IETF > Working Group, so that maybe we can get other FSAL feedback, too. > > Is anybody specifically interested in helping design the API? As the proposer of this idea, I'm interested in seeing experimental prototypes that help us establish and refine something that works. Let's post running code, and then write specs. That said, upstream participation is welcome. 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 ------------------------------------------------------------------------------ Announcing the Oxford Dictionaries API! The API offers world-renowned dictionary content that is easy and intuitive to access. Sign up for an account today to start using our lexical data to power your apps and projects. Get started today and enter our developer competition. http://sdm.link/oxford _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
