From: NeilBrown <neilb@suse.com>
To: Olga Kornievskaia <aglo@umich.edu>, Chuck Lever <chuck.lever@oracle.com>
Cc: Tom Talpey <tom@talpey.com>,
Anna Schumaker <Anna.Schumaker@netapp.com>,
Trond Myklebust <trondmy@hammerspace.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/9] Multiple network connections for a single NFS mount.
Date: Wed, 12 Jun 2019 09:02:57 +1000 [thread overview]
Message-ID: <87d0jjwwri.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <CAN-5tyFP9qK9Tjv-FCeZJGMnhhnsZh0+VCguuRaDOG2kB9A-OQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On Tue, Jun 11 2019, Olga Kornievskaia wrote:
>
> Neil,
>
> What's your experience with providing "nosharedtransport" option to
> the SLE customers? Were you are having customers coming back and
> complain about the multiple connections issues?
Never had customers come back at all.
Every major SLE release saw a request that we preserve this non-upstream
functionality, but we got very little information about how it was being
used, and how well it performed.
>
> When the connection is having issues, because we have to retransmit
> from the same port, there isn't anything to be done but wait for the
> new connection to be established and add to the latency of the
> operation over the bad connection. There could be smarts added to the
> (new) scheduler to grade the connections and if connection is having
> issues not assign tasks to it until it recovers but all that are
> additional improvement and I don't think we should restrict
> connections right of the bet. This is an option that allows for 8, 10,
> 16 (32) connections but it doesn't mean customer have to set such high
> value and we can recommend for low values.
The current load-balancing code will stop adding new tasks to any
connection that already has more than the average number of tasks
pending.
So if a connection breaks (which would require lots of packet loss I
think), then it will soon be ignored by new tasks. Those tasks which
have been assigned to it will just have to wait for the reconnect.
In terms of a maximum number of connections, I don't think it is our place
to stop people shooting themselves in the foot.
Given the limit of 1024 reserved ports, I can justify enforcing a limit
of (say) 256. Forcing a limit lower than that might just stop people
from experimenting, and I think we want people to experiment.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-06-11 23:03 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-30 0:41 [PATCH 0/9] Multiple network connections for a single NFS mount NeilBrown
2019-05-30 0:41 ` [PATCH 3/9] NFS: send state management on a single connection NeilBrown
2019-07-23 18:11 ` Schumaker, Anna
2019-07-23 22:54 ` NeilBrown
2019-07-31 2:05 ` [PATCH] NFS: add flags arg to nfs4_call_sync_sequence() NeilBrown
2019-05-30 0:41 ` [PATCH 9/9] NFS: Allow multiple connections to a NFSv2 or NFSv3 server NeilBrown
2019-05-30 0:41 ` [PATCH 6/9] NFS: Add a mount option to specify number of TCP connections to use NeilBrown
2019-05-30 0:41 ` [PATCH 4/9] SUNRPC: enhance rpc_clnt_show_stats() to report on all xprts NeilBrown
2019-05-30 0:41 ` [PATCH 1/9] SUNRPC: Add basic load balancing to the transport switch NeilBrown
2019-05-30 0:41 ` [PATCH 2/9] SUNRPC: Allow creation of RPC clients with multiple connections NeilBrown
2019-05-30 0:41 ` [PATCH 8/9] pNFS: Allow multiple connections to the DS NeilBrown
2019-05-30 0:41 ` [PATCH 7/9] NFSv4: Allow multiple connections to NFSv4.x servers NeilBrown
2019-05-30 0:41 ` [PATCH 5/9] SUNRPC: add links for all client xprts to debugfs NeilBrown
2019-05-30 17:05 ` [PATCH 0/9] Multiple network connections for a single NFS mount Tom Talpey
2019-05-30 17:20 ` Olga Kornievskaia
2019-05-30 17:41 ` Tom Talpey
2019-05-30 18:41 ` Olga Kornievskaia
2019-05-31 1:45 ` Tom Talpey
2019-05-30 22:38 ` NeilBrown
2019-05-31 1:48 ` Tom Talpey
2019-05-31 2:31 ` NeilBrown
2019-05-31 12:39 ` Tom Talpey
2019-05-30 23:53 ` Rick Macklem
2019-05-31 0:15 ` J. Bruce Fields
2019-05-31 1:01 ` NeilBrown
2019-05-31 2:20 ` Rick Macklem
2019-05-31 12:36 ` Tom Talpey
2019-05-31 13:33 ` Trond Myklebust
2019-05-30 17:56 ` Chuck Lever
2019-05-30 18:59 ` Olga Kornievskaia
2019-05-30 22:56 ` NeilBrown
2019-05-31 13:46 ` Chuck Lever
2019-05-31 15:38 ` J. Bruce Fields
2019-06-11 1:09 ` NeilBrown
2019-06-11 14:51 ` Chuck Lever
2019-06-11 15:05 ` Tom Talpey
2019-06-11 15:20 ` Trond Myklebust
2019-06-11 15:35 ` Chuck Lever
2019-06-11 16:41 ` Trond Myklebust
2019-06-11 17:32 ` Chuck Lever
2019-06-11 17:44 ` Trond Myklebust
2019-06-12 12:34 ` Steve Dickson
2019-06-12 12:47 ` Trond Myklebust
2019-06-12 13:10 ` Trond Myklebust
2019-06-11 15:34 ` Olga Kornievskaia
2019-06-11 17:46 ` Chuck Lever
2019-06-11 19:13 ` Olga Kornievskaia
2019-06-11 20:02 ` Tom Talpey
2019-06-11 20:09 ` Chuck Lever
2019-06-11 21:10 ` Olga Kornievskaia
2019-06-11 21:35 ` Tom Talpey
2019-06-11 22:55 ` NeilBrown
2019-06-12 12:55 ` Tom Talpey
2019-06-11 23:02 ` NeilBrown [this message]
2019-06-11 23:21 ` NeilBrown
2019-06-12 12:52 ` Tom Talpey
2019-06-11 23:42 ` NeilBrown
2019-06-12 12:39 ` Steve Dickson
2019-06-12 17:36 ` Chuck Lever
2019-06-12 23:03 ` NeilBrown
2019-06-13 16:13 ` Chuck Lever
2019-06-12 1:49 ` NeilBrown
2019-06-12 18:32 ` Chuck Lever
2019-06-12 23:37 ` NeilBrown
2019-06-13 16:27 ` Chuck Lever
2019-05-31 0:24 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0jjwwri.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=Anna.Schumaker@netapp.com \
--cc=aglo@umich.edu \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=tom@talpey.com \
--cc=trondmy@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).