> On Jun 11, 2019, at 12:41 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-06-11 at 11:35 -0400, Chuck Lever wrote: >>> On Jun 11, 2019, at 11:20 AM, Trond Myklebust < >>> trondmy@xxxxxxxxxxxxxxx> wrote: >>> >>> On Tue, 2019-06-11 at 10:51 -0400, Chuck Lever wrote: >>> >>>> If maxconn is a hint, when does the client open additional >>>> connections? >>> >>> As I've already stated, that functionality is not yet available. >>> When >>> it is, it will be under the control of a userspace daemon that can >>> decide on a policy in accordance with a set of user specified >>> requirements. >> >> Then why do we need a mount option at all? >> > > For one thing, it allows people to play with this until we have a fully > automated solution. The fact that people are actually pulling down > these patches, forward porting them and trying them out would indicate > that there is interest in doing so. Agreed that it demonstrates that folks are interested in having multiple connections. I count myself among them. > Secondly, if your policy is 'I just want n connections' because that > fits your workload requirements (e.g. because said workload is both > latency sensitive and bursty), then a daemon solution would be > unnecessary, and may be error prone. Why wouldn't that be the default out-of-the-shrinkwrap configuration that is installed by nfs-utils? > A mount option is helpful in this case, because you can perform the > setup through the normal fstab or autofs config file configuration > route. It also make sense if you have a nfsroot setup. NFSROOT is the only usage scenario where I see a mount option being a superior administrative interface. However I don't feel that NFSROOT is going to host workloads that would need multiple connections. KIS > Finally, even if you do want to have a daemon manage your transport, > configuration, you do want a mechanism to help it reach an equilibrium > state quickly. Connections take time to bring up and tear down because > performance measurements take time to build up sufficient statistical > precision. Furthermore, doing so comes with a number of hidden costs, > e.g.: chewing up privileged port numbers by putting them in a TIME_WAIT > state. If you know that a given server is always subject to heavy > traffic, then initialising the number of connections appropriately has > value. Again, I don't see how this is not something a config file can do. The stated intent of "nconnect" way back when was for experimentation. It works great for that! I don't see it as a desirable long-term administrative interface, though. I'd rather not nail in a new mount option that we actually plan to obsolete in favor of an automated mechanism. I'd rather see us design the administrative interface with automation from the start. That will have a lower long-term maintenance cost. Again, I'm not objecting to support for multiple connections. It's just that adding a mount option doesn't feel like a friendly or finished interface for actual users. A config file (or re-using nfs.conf) seems to me like a better approach. -- Chuck Lever
