On Fri, May 31 2019, Chuck Lever wrote: >> On May 30, 2019, at 6:56 PM, NeilBrown <neilb@xxxxxxxx> wrote: >> >> On Thu, May 30 2019, Chuck Lever wrote: >> >>> Hi Neil- >>> >>> Thanks for chasing this a little further. >>> >>> >>>> On May 29, 2019, at 8:41 PM, NeilBrown <neilb@xxxxxxxx> wrote: >>>> >>>> This patch set is based on the patches in the multipath_tcp branch of >>>> git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git >>>> >>>> I'd like to add my voice to those supporting this work and wanting to >>>> see it land. >>>> We have had customers/partners wanting this sort of functionality for >>>> years. In SLES releases prior to SLE15, we've provide a >>>> "nosharetransport" mount option, so that several filesystem could be >>>> mounted from the same server and each would get its own TCP >>>> connection. >>> >>> Is it well understood why splitting up the TCP connections result >>> in better performance? >>> >>> >>>> In SLE15 we are using this 'nconnect' feature, which is much nicer. >>>> >>>> Partners have assured us that it improves total throughput, >>>> particularly with bonded networks, but we haven't had any concrete >>>> data until Olga Kornievskaia provided some concrete test data - thanks >>>> Olga! >>>> >>>> My understanding, as I explain in one of the patches, is that parallel >>>> hardware is normally utilized by distributing flows, rather than >>>> packets. This avoid out-of-order deliver of packets in a flow. >>>> So multiple flows are needed to utilizes parallel hardware. >>> >>> Indeed. >>> >>> However I think one of the problems is what happens in simpler scenarios. >>> We had reports that using nconnect > 1 on virtual clients made things >>> go slower. It's not always wise to establish multiple connections >>> between the same two IP addresses. It depends on the hardware on each >>> end, and the network conditions. >> >> This is a good argument for leaving the default at '1'. When >> documentation is added to nfs(5), we can make it clear that the optimal >> number is dependant on hardware. > > Is there any visibility into the NIC hardware that can guide this setting? > I doubt it, partly because there is more than just the NIC hardware at issue. There is also the server-side hardware and possibly hardware in the middle. > >>> What about situations where the network capabilities between server and >>> client change? Problem is that neither endpoint can detect that; TCP >>> usually just deals with it. >> >> Being able to manually change (-o remount) the number of connections >> might be useful... > > Ugh. I have problems with the administrative interface for this feature, > and this is one of them. > > Another is what prevents your client from using a different nconnect= > setting on concurrent mounts of the same server? It's another case of a > per-mount setting being used to control a resource that is shared across > mounts. I think that horse has well and truly bolted. It would be nice to have a "server" abstraction visible to user-space where we could adjust settings that make sense server-wide, and then a way to mount individual filesystems from that "server" - but we don't. Probably the best we can do is to document (in nfs(5)) which options are per-server and which are per-mount. > > Adding user tunables has never been known to increase the aggregate > amount of happiness in the universe. I really hope we can come up with > a better administrative interface... ideally, none would be best. I agree that none would be best. It isn't clear to me that that is possible. At present, we really don't have enough experience with this functionality to be able to say what the trade-offs are. If we delay the functionality until we have the perfect interface, we may never get that experience. We can document "nconnect=" as a hint, and possibly add that "nconnect=1" is a firm guarantee that more will not be used. Then further down the track, we might change the actual number of connections automatically if a way can be found to do that without cost. Do you have any objections apart from the nconnect= mount option? Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
