Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2829547pxv; Mon, 12 Jul 2021 02:59:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzytsaE0mvS2Gn65L8Wwnt+LDVj5ARlxVlvm7F4YFBJs9t4F8GZGAQ8chZg9O1tCSnyHUAq X-Received: by 2002:a5e:8208:: with SMTP id l8mr38747628iom.197.1626083999434; Mon, 12 Jul 2021 02:59:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626083999; cv=none; d=google.com; s=arc-20160816; b=w2mxZQO//l4XCz53KwwyrWnHdj9axp2dcN88U7HHec17/gwqX8w1x4I9YILCWQ3vXU Gp9t8Nm8wAE8dAPM15bNC1xfGIYBtVXPMUqdEW87/kseTFtN2D0wdhZ4Rap9279mBVho jnzMW9uj0BBqdIfJnsd+vAvw4QW55iSndrIfPHPaR+pV2dQhdIkbQWDb5qEkIA4oa5Ra srWx570qN7wQUGY1tQkawe+BcOIcSIvVWWR3xOuPfyYUjQFPnBEU8RMWzev0doCAO8X8 eO61LwzwWVec/q55sTcOJzkTgLbTujMd/JnDhb0JgupJqMWFLqYkf6llJI+QxxSQVyK5 dYwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=MZUkFzl4bf/AYHaAatRrYIQbr+askC854bMoTbBiljk=; b=xI/uklmPGeWlizmJ9s6vDt+vq+p9bAkhzkYQVON5Rq3pSlIKE5HkkAEaDBZeRj/T6M RRBBEo9Z6eUwuDuPHQG5rnM5aYGgXQuItaLrEmt5o1F/+HVqikDrStESSkQKL5nWy/ND IZyee/ernlQq9htCNzBfU0ID/s475NNLhC7B51c7a2WLHxLKnNjheH7ep4xdmySRavkt 266sRx9LqH/TnJ/mjirobQHtZlQ1uilufu+c7kuM8+5TIETic+9PNmPQcTrMCjC0gJYA HQbPJRLeyvnrFgccYZOwXE90LaoDXjL9uGBKbQuf4H8Bul1ij2xySogiMI5hgn6iy7hL t/6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lyGBZLww; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si16572186jar.0.2021.07.12.02.59.46; Mon, 12 Jul 2021 02:59:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=lyGBZLww; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240225AbhGLHDa (ORCPT + 99 others); Mon, 12 Jul 2021 03:03:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:42444 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237585AbhGLGq3 (ORCPT ); Mon, 12 Jul 2021 02:46:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5C188610CA; Mon, 12 Jul 2021 06:42:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626072125; bh=Ol69Wz7c1pJRaqSzjdYyZvKqATdKAoFkljnjkHWq3rw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lyGBZLwwAihosT1xHyprVKWtgYj5X+T2sfrc7J1X/6N0qzD78s9SoW9XwZd9lXR/5 ne4P2dwP0D4SFfse47cEnKfi0ztcrCmSaaSFCi62nk5tnpZFHiHYJ4zaGH5RDU/rO4 MG2ahYm44e+IflGoK9OrgHpbAEUKvpM6VjXQMAcU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jack Wang , Md Haris Iqbal , Gioh Kim , Leon Romanovsky , Jason Gunthorpe , Sasha Levin Subject: [PATCH 5.10 365/593] RDMA/rtrs-srv: Set minimal max_send_wr and max_recv_wr Date: Mon, 12 Jul 2021 08:08:45 +0200 Message-Id: <20210712060926.708182193@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210712060843.180606720@linuxfoundation.org> References: <20210712060843.180606720@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jack Wang [ Upstream commit 5e91eabf66c854f16ca2e954e5c68939bc81601e ] Currently rtrs when create_qp use a coarse numbers (bigger in general), which leads to hardware create more resources which only waste memory with no benefits. For max_send_wr, we don't really need alway max_qp_wr size when creating qp, reduce it to cq_size. For max_recv_wr, cq_size is enough. With the patch when sess_queue_depth=128, per session (2 paths) memory consumption reduced from 188 MB to 65MB When always_invalidate is enabled, we need send more wr, so treat it special. Fixes: 9cb837480424e ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20210614090337.29557-2-jinpu.wang@ionos.com Signed-off-by: Jack Wang Reviewed-by: Md Haris Iqbal Signed-off-by: Gioh Kim Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin --- drivers/infiniband/ulp/rtrs/rtrs-srv.c | 38 +++++++++++++++++--------- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv.c b/drivers/infiniband/ulp/rtrs/rtrs-srv.c index e1041023d143..b033bfa9f383 100644 --- a/drivers/infiniband/ulp/rtrs/rtrs-srv.c +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv.c @@ -1614,7 +1614,7 @@ static int create_con(struct rtrs_srv_sess *sess, struct rtrs_sess *s = &sess->s; struct rtrs_srv_con *con; - u32 cq_size, wr_queue_size; + u32 cq_size, max_send_wr, max_recv_wr, wr_limit; int err, cq_vector; con = kzalloc(sizeof(*con), GFP_KERNEL); @@ -1635,30 +1635,42 @@ static int create_con(struct rtrs_srv_sess *sess, * All receive and all send (each requiring invalidate) * + 2 for drain and heartbeat */ - wr_queue_size = SERVICE_CON_QUEUE_DEPTH * 3 + 2; - cq_size = wr_queue_size; + max_send_wr = SERVICE_CON_QUEUE_DEPTH * 2 + 2; + max_recv_wr = SERVICE_CON_QUEUE_DEPTH + 2; + cq_size = max_send_wr + max_recv_wr; } else { - /* - * If we have all receive requests posted and - * all write requests posted and each read request - * requires an invalidate request + drain - * and qp gets into error state. - */ - cq_size = srv->queue_depth * 3 + 1; /* * In theory we might have queue_depth * 32 * outstanding requests if an unsafe global key is used * and we have queue_depth read requests each consisting * of 32 different addresses. div 3 for mlx5. */ - wr_queue_size = sess->s.dev->ib_dev->attrs.max_qp_wr / 3; + wr_limit = sess->s.dev->ib_dev->attrs.max_qp_wr / 3; + /* when always_invlaidate enalbed, we need linv+rinv+mr+imm */ + if (always_invalidate) + max_send_wr = + min_t(int, wr_limit, + srv->queue_depth * (1 + 4) + 1); + else + max_send_wr = + min_t(int, wr_limit, + srv->queue_depth * (1 + 2) + 1); + + max_recv_wr = srv->queue_depth + 1; + /* + * If we have all receive requests posted and + * all write requests posted and each read request + * requires an invalidate request + drain + * and qp gets into error state. + */ + cq_size = max_send_wr + max_recv_wr; } - atomic_set(&con->sq_wr_avail, wr_queue_size); + atomic_set(&con->sq_wr_avail, max_send_wr); cq_vector = rtrs_srv_get_next_cq_vector(sess); /* TODO: SOFTIRQ can be faster, but be careful with softirq context */ err = rtrs_cq_qp_create(&sess->s, &con->c, 1, cq_vector, cq_size, - wr_queue_size, wr_queue_size, + max_send_wr, max_recv_wr, IB_POLL_WORKQUEUE); if (err) { rtrs_err(s, "rtrs_cq_qp_create(), err: %d\n", err); -- 2.30.2