All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
To: Tom Talpey <tom-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>,
	Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>,
	Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux NFS Mailing List
	<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v1 09/20] xprtrdma: Limit the number of rpcrdma_mws
Date: Wed, 8 Jun 2016 15:06:56 +0000	[thread overview]
Message-ID: <8FF9BF11-C5BF-4418-9A84-AAD7A6D6321D@primarydata.com> (raw)
In-Reply-To: <c43e37cd-71ea-8629-20f2-bcd674d50b83-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>



On 6/8/16, 10:54, "linux-nfs-owner@vger.kernel.org on behalf of Tom Talpey" <linux-nfs-owner@vger.kernel.org on behalf of tom@talpey.com> wrote:

>On 6/7/2016 6:01 PM, Jason Gunthorpe wrote:
>> On Tue, Jun 07, 2016 at 05:51:04PM -0400, Chuck Lever wrote:
>>
>>> There is a practical number of MRs that can be allocated
>>> per device, I thought. And each MR consumes some amount
>>> of host memory.
>>
>>> xprtrdma is happy to allocate thousands of MRs per QP/PD
>>> pair, but that isn't practical as you start adding more
>>> transports/connections.
>>
>> Yes, this is all sane and valid.
>>
>> Typically you'd target a concurrency limit per QP and allocate
>> everything (# MRs, sq,rq,cq depth, etc) in accordance with that goal,
>> I'd also suggest that target concurrency is probably a user tunable..
>
>This is already present - it's the RPC slot table depth. It would be
>great, IMO, to make this a mount parameter since it is transport- and
>also server-dependent, but currently I believe it is just a kernel
>RPC module parameter.

That would be a mount parameter which would only apply to RDMA since everything else uses dynamic slot allocation these days. I’d prefer to avoid that.

Trond


WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy@primarydata.com>
To: Tom Talpey <tom@talpey.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Chuck Lever <chuck.lever@oracle.com>
Cc: linux-rdma <linux-rdma@vger.kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 09/20] xprtrdma: Limit the number of rpcrdma_mws
Date: Wed, 8 Jun 2016 15:06:56 +0000	[thread overview]
Message-ID: <8FF9BF11-C5BF-4418-9A84-AAD7A6D6321D@primarydata.com> (raw)
In-Reply-To: <c43e37cd-71ea-8629-20f2-bcd674d50b83@talpey.com>

DQoNCk9uIDYvOC8xNiwgMTA6NTQsICJsaW51eC1uZnMtb3duZXJAdmdlci5rZXJuZWwub3JnIG9u
IGJlaGFsZiBvZiBUb20gVGFscGV5IiA8bGludXgtbmZzLW93bmVyQHZnZXIua2VybmVsLm9yZyBv
biBiZWhhbGYgb2YgdG9tQHRhbHBleS5jb20+IHdyb3RlOg0KDQo+T24gNi83LzIwMTYgNjowMSBQ
TSwgSmFzb24gR3VudGhvcnBlIHdyb3RlOg0KPj4gT24gVHVlLCBKdW4gMDcsIDIwMTYgYXQgMDU6
NTE6MDRQTSAtMDQwMCwgQ2h1Y2sgTGV2ZXIgd3JvdGU6DQo+Pg0KPj4+IFRoZXJlIGlzIGEgcHJh
Y3RpY2FsIG51bWJlciBvZiBNUnMgdGhhdCBjYW4gYmUgYWxsb2NhdGVkDQo+Pj4gcGVyIGRldmlj
ZSwgSSB0aG91Z2h0LiBBbmQgZWFjaCBNUiBjb25zdW1lcyBzb21lIGFtb3VudA0KPj4+IG9mIGhv
c3QgbWVtb3J5Lg0KPj4NCj4+PiB4cHJ0cmRtYSBpcyBoYXBweSB0byBhbGxvY2F0ZSB0aG91c2Fu
ZHMgb2YgTVJzIHBlciBRUC9QRA0KPj4+IHBhaXIsIGJ1dCB0aGF0IGlzbid0IHByYWN0aWNhbCBh
cyB5b3Ugc3RhcnQgYWRkaW5nIG1vcmUNCj4+PiB0cmFuc3BvcnRzL2Nvbm5lY3Rpb25zLg0KPj4N
Cj4+IFllcywgdGhpcyBpcyBhbGwgc2FuZSBhbmQgdmFsaWQuDQo+Pg0KPj4gVHlwaWNhbGx5IHlv
dSdkIHRhcmdldCBhIGNvbmN1cnJlbmN5IGxpbWl0IHBlciBRUCBhbmQgYWxsb2NhdGUNCj4+IGV2
ZXJ5dGhpbmcgKCMgTVJzLCBzcSxycSxjcSBkZXB0aCwgZXRjKSBpbiBhY2NvcmRhbmNlIHdpdGgg
dGhhdCBnb2FsLA0KPj4gSSdkIGFsc28gc3VnZ2VzdCB0aGF0IHRhcmdldCBjb25jdXJyZW5jeSBp
cyBwcm9iYWJseSBhIHVzZXIgdHVuYWJsZS4uDQo+DQo+VGhpcyBpcyBhbHJlYWR5IHByZXNlbnQg
LSBpdCdzIHRoZSBSUEMgc2xvdCB0YWJsZSBkZXB0aC4gSXQgd291bGQgYmUNCj5ncmVhdCwgSU1P
LCB0byBtYWtlIHRoaXMgYSBtb3VudCBwYXJhbWV0ZXIgc2luY2UgaXQgaXMgdHJhbnNwb3J0LSBh
bmQNCj5hbHNvIHNlcnZlci1kZXBlbmRlbnQsIGJ1dCBjdXJyZW50bHkgSSBiZWxpZXZlIGl0IGlz
IGp1c3QgYSBrZXJuZWwNCj5SUEMgbW9kdWxlIHBhcmFtZXRlci4NCg0KVGhhdCB3b3VsZCBiZSBh
IG1vdW50IHBhcmFtZXRlciB3aGljaCB3b3VsZCBvbmx5IGFwcGx5IHRvIFJETUEgc2luY2UgZXZl
cnl0aGluZyBlbHNlIHVzZXMgZHluYW1pYyBzbG90IGFsbG9jYXRpb24gdGhlc2UgZGF5cy4gSeKA
mWQgcHJlZmVyIHRvIGF2b2lkIHRoYXQuDQoNClRyb25kDQoNCg==


  parent reply	other threads:[~2016-06-08 15:06 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-07 19:46 [PATCH v1 00/20] NFS/RDMA client patches proposed for v4.8 Chuck Lever
2016-06-07 19:46 ` Chuck Lever
     [not found] ` <20160607194001.18401.88592.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2016-06-07 19:46   ` [PATCH v1 01/20] xprtrdma: Remove ALLPHYSICAL memory registration mode Chuck Lever
2016-06-07 19:46     ` Chuck Lever
2016-06-07 19:46   ` [PATCH v1 02/20] xprtrdma: Refactor ->ro_init Chuck Lever
2016-06-07 19:46     ` Chuck Lever
     [not found]     ` <20160607194635.18401.66399.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2016-06-08 17:48       ` Anna Schumaker
2016-06-08 17:48         ` Anna Schumaker
2016-06-07 19:46   ` [PATCH v1 03/20] xprtrdma: Create common scatterlist fields in rpcrdma_mw Chuck Lever
2016-06-07 19:46     ` Chuck Lever
2016-06-07 19:46   ` [PATCH v1 04/20] xprtrdma: Use scatterlist for DMA mapping and unmapping under FMR Chuck Lever
2016-06-07 19:46     ` Chuck Lever
2016-06-07 19:46   ` [PATCH v1 05/20] xprtrdma: Remove rpcrdma_map_one() and friends Chuck Lever
2016-06-07 19:46     ` Chuck Lever
2016-06-07 19:47   ` [PATCH v1 06/20] xprtrdma: Refactor MR recovery work queues Chuck Lever
2016-06-07 19:47     ` Chuck Lever
2016-06-07 19:47   ` [PATCH v1 07/20] xprtrdma: Place registered MWs on a per-req list Chuck Lever
2016-06-07 19:47     ` Chuck Lever
2016-06-07 19:47   ` [PATCH v1 08/20] xprtrdma: Reply buffer exhaustion can be catastrophic Chuck Lever
2016-06-07 19:47     ` Chuck Lever
2016-06-07 19:47   ` [PATCH v1 09/20] xprtrdma: Limit the number of rpcrdma_mws Chuck Lever
2016-06-07 19:47     ` Chuck Lever
     [not found]     ` <20160607194732.18401.71941.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2016-06-07 20:49       ` Jason Gunthorpe
2016-06-07 20:49         ` Jason Gunthorpe
     [not found]         ` <20160607204941.GA7991-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-06-07 21:09           ` Chuck Lever
2016-06-07 21:09             ` Chuck Lever
     [not found]             ` <F1820E16-A2BF-4529-A5C9-59C9AD57369A-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-06-07 21:28               ` Jason Gunthorpe
2016-06-07 21:28                 ` Jason Gunthorpe
     [not found]                 ` <20160607212831.GA9192-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-06-07 21:51                   ` Chuck Lever
2016-06-07 21:51                     ` Chuck Lever
     [not found]                     ` <D90190F5-ACCB-45D8-B08D-B75023ED6240-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-06-07 22:01                       ` Jason Gunthorpe
2016-06-07 22:01                         ` Jason Gunthorpe
     [not found]                         ` <20160607220107.GA9982-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-06-08 14:54                           ` Tom Talpey
2016-06-08 14:54                             ` Tom Talpey
     [not found]                             ` <c43e37cd-71ea-8629-20f2-bcd674d50b83-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>
2016-06-08 15:06                               ` Trond Myklebust [this message]
2016-06-08 15:06                                 ` Trond Myklebust
     [not found]                                 ` <8FF9BF11-C5BF-4418-9A84-AAD7A6D6321D-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
2016-06-08 17:40                                   ` Jason Gunthorpe
2016-06-08 17:40                                     ` Jason Gunthorpe
     [not found]                                     ` <20160608174014.GB30822-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-06-08 17:50                                       ` Trond Myklebust
2016-06-08 17:50                                         ` Trond Myklebust
2016-06-08 17:53                                       ` Chuck Lever
2016-06-08 17:53                                         ` Chuck Lever
     [not found]                                         ` <240BF8C6-AB80-4A27-8C38-1FE9BB02AD66-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2016-06-08 18:45                                           ` Tom Talpey
2016-06-08 18:45                                             ` Tom Talpey
2016-06-07 19:47   ` [PATCH v1 10/20] xprtrdma: Chunk list encoders no longer share one rl_segments array Chuck Lever
2016-06-07 19:47     ` Chuck Lever
2016-06-07 19:47   ` [PATCH v1 11/20] xprtrdma: rpcrdma_inline_fixup() overruns the receive page list Chuck Lever
2016-06-07 19:47     ` Chuck Lever
2016-06-07 19:47   ` [PATCH v1 12/20] xprtrdma: Do not update {head, tail}.iov_len in rpcrdma_inline_fixup() Chuck Lever
2016-06-07 19:47     ` Chuck Lever
2016-06-07 19:48   ` [PATCH v1 13/20] xprtrdma: Update only specific fields in private receive buffer Chuck Lever
2016-06-07 19:48     ` Chuck Lever
2016-06-07 19:48   ` [PATCH v1 14/20] xprtrdma: Clean up fixup_copy_count accounting Chuck Lever
2016-06-07 19:48     ` Chuck Lever
2016-06-07 19:48   ` [PATCH v1 15/20] xprtrdma: No direct data placement with krb5i and krb5p Chuck Lever
2016-06-07 19:48     ` Chuck Lever
2016-06-07 19:48   ` [PATCH v1 16/20] svc: Avoid garbage replies when pc_func() returns rpc_drop_reply Chuck Lever
2016-06-07 19:48     ` Chuck Lever
2016-06-07 19:48   ` [PATCH v1 17/20] NFS: Don't drop CB requests with invalid principals Chuck Lever
2016-06-07 19:48     ` Chuck Lever
2016-06-07 19:48   ` [PATCH v1 18/20] xprtrdma: Eliminate rpcrdma_receive_worker() Chuck Lever
2016-06-07 19:48     ` Chuck Lever
2016-06-07 19:48   ` [PATCH v1 19/20] xprtrdma: Eliminate INLINE_THRESHOLD macros Chuck Lever
2016-06-07 19:48     ` Chuck Lever
2016-06-07 19:49   ` [PATCH v1 20/20] xprtrdma: Relocate connection helper functions Chuck Lever
2016-06-07 19:49     ` Chuck Lever

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=8FF9BF11-C5BF-4418-9A84-AAD7A6D6321D@primarydata.com \
    --to=trondmy-7i+n7zu2hftekmmhf/gkza@public.gmane.org \
    --cc=chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tom-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.