public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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