From: Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC 0/3] Proposal for exposing rdma_rw MR factor
Date: Wed, 2 Aug 2017 10:20:43 +0300 [thread overview]
Message-ID: <20170802072043.GZ13672@mtr-leonro.local> (raw)
In-Reply-To: <20170801205334.15781.18761.stgit-Hs+gFlyCn65vLzlybtyyYzGyq/o6K9yX@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
On Tue, Aug 01, 2017 at 05:06:51PM -0400, Chuck Lever wrote:
> Since I converted NFSD to use the new rdma_rw API, I've been
> struggling with how NFSD determines the size of its send CQ, and how
> it provisions its send queue limit (ie, when it waits for more send
> queue entries to become available).
>
> The problem arises because rdma_rw hides the exact number of send
> WQEs it has provisioned. It determines this number based on the MR
> registration mode (FRWR for iWARP devices, local DMA rkey for
> others), but the mode itself is no longer exposed to ULPs.
>
> Thus when FRWR is in use, rdma_rw adds more WQEs, but NFSD is no
> longer aware of this, does not provision a larger CQ, and does not
> raise its send queue accounting limit. That means the extra WQEs are
> never really used.
>
> At LSF this year, Christoph and Sagi proposed a simple API that
> expose information about how many CQ entries are needed so that ULPs
> can provision their CQs more accurately.
Indeed clean API. Does it make sense to get rid of sc_max_requests and
use this exported value directly?
>
> The first patch here is a pre-requisite for the third. The second
> patch adds the new API. The third patch changes NFSD to use the new
> API to provision its CQ and send queue accounting accurately.
>
> This approach was tested using the (fixed) force_mr core module
> parameter.
Good, I liked the word "tested" in the sentence :).
>
>
> ---
>
> Chuck Lever (3):
> svcrdma: Limit RQ depth
> rdma core: Add rdma_rw_mr_payload()
> svcrdma: Estimate Send Queue depth properly
>
>
> drivers/infiniband/core/rw.c | 24 ++++++++++++++++++++
> include/rdma/rw.h | 2 ++
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 36 +++++++++++++++++++++---------
> 3 files changed, 51 insertions(+), 11 deletions(-)
>
> --
> Chuck Lever
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-08-02 7:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-01 21:06 [PATCH RFC 0/3] Proposal for exposing rdma_rw MR factor Chuck Lever
[not found] ` <20170801205334.15781.18761.stgit-Hs+gFlyCn65vLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2017-08-01 21:06 ` [PATCH RFC 1/3] svcrdma: Limit RQ depth Chuck Lever
2017-08-01 21:07 ` [PATCH RFC 2/3] rdma core: Add rdma_rw_mr_payload() Chuck Lever
[not found] ` <20170801210707.15781.36464.stgit-Hs+gFlyCn65vLzlybtyyYzGyq/o6K9yX@public.gmane.org>
2017-08-18 16:51 ` Doug Ledford
2017-08-01 21:07 ` [PATCH RFC 3/3] svcrdma: Estimate Send Queue depth properly Chuck Lever
2017-08-02 7:20 ` Leon Romanovsky [this message]
[not found] ` <20170802072043.GZ13672-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2017-08-02 18:06 ` [PATCH RFC 0/3] Proposal for exposing rdma_rw MR factor Chuck Lever
2017-08-08 18:28 ` Chuck Lever
[not found] ` <D8576C0A-6588-49D1-A2F9-AD39FB2E5FCE-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-08-16 15:50 ` Chuck Lever
[not found] ` <6EAEEE15-819E-4CE2-8C67-997A244919FB-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2017-08-18 16:52 ` Doug Ledford
[not found] ` <1503075123.2598.27.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-08-18 16:53 ` 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=20170802072043.GZ13672@mtr-leonro.local \
--to=leon-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox