From patchwork Wed May 10 10:45:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Selvin Xavier X-Patchwork-Id: 9719669 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 85F4B60236 for ; Wed, 10 May 2017 10:46:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7A84128576 for ; Wed, 10 May 2017 10:46:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6E14F2857F; Wed, 10 May 2017 10:46:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0BDDA28576 for ; Wed, 10 May 2017 10:46:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752628AbdEJKq3 (ORCPT ); Wed, 10 May 2017 06:46:29 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:34277 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752213AbdEJKq2 (ORCPT ); Wed, 10 May 2017 06:46:28 -0400 Received: by mail-qk0-f178.google.com with SMTP id k74so24702720qke.1 for ; Wed, 10 May 2017 03:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=K3kMpGcL+KdZhfV1OfGiRMhcCJlWbyiHTHQ1YjGJM+s=; b=YXkOlsIIap2BPScoJ3jYiUbacy/UU7X83YfZ9kP3UtMvszKBNHKfXnn5fVeFupT2n2 xAUuWGmvSVJaPU/Wt9a5Q3n/gK4nDWOkWORPiaf3YLbF5Ea54zac5/mggA1QIlL3fwMl tq1jtTXaXlMh9jelIqyszpyptizGjM6vI+Be8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=K3kMpGcL+KdZhfV1OfGiRMhcCJlWbyiHTHQ1YjGJM+s=; b=ovlkxLiDnvedfchHQRao9Mh5/XeumqDIZeB6FNuOUj0Qn5SaqP6CvbuD1b3vrstqnb cHI5o4WUGWwFohXqcxX6WY+i0L07n+j1f/mQnPK31nUoqmhlhR7z5a0DcMNgBq4rSbPw lmpp8F4+8dDCltlP3REXEQIMSmQWZ/JgLVjtYJVuk6QKT3Quo8zXQQ7blOy8chAZdPUi vgZHK7jQ2aaZDwTxaf3dPKf9J7HpnyWZfhcs1p/HAXYURiMLrvoINUgS6Xj6no4V6eph iUV8rBGBpFzlsjMedhPEcIpb3GIZ5FK663m0e9PiCgijVRLaVpD7EV/rAToFaOOgsSav n8Jg== X-Gm-Message-State: AODbwcCkBLjzqQxQ0b4BIEXtREZmeWapTniwu7yKKk6NY0Emo1CMgG/B 6Ut+ZtTbe/Q9xRW9 X-Received: by 10.55.155.16 with SMTP id d16mr4883373qke.174.1494413187640; Wed, 10 May 2017 03:46:27 -0700 (PDT) Received: from dhcp-10-192-206-197.iig.avagotech.net ([192.19.239.250]) by smtp.gmail.com with ESMTPSA id k10sm1868531qke.3.2017.05.10.03.46.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 03:46:27 -0700 (PDT) From: Selvin Xavier To: dledford@redhat.com, linux-rdma@vger.kernel.org Cc: Eddie Wai , Selvin Xavier Subject: [PATCH for-next 12/14] RDMA/bnxt_re: Fixed the max_rd_atomic support for initiator and destination QP Date: Wed, 10 May 2017 03:45:37 -0700 Message-Id: <1494413139-11883-13-git-send-email-selvin.xavier@broadcom.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1494413139-11883-1-git-send-email-selvin.xavier@broadcom.com> References: <1494413139-11883-1-git-send-email-selvin.xavier@broadcom.com> Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Eddie Wai There's a couple of bugs in the support of max_rd_atomic and max_dest_rd_atomic. In the modify_qp, if the requested max_rd_atomic, which is the ORRQ size, is greater than what the chip can support, then we have to cap the request to chip max as we can't have the HW overflow the ORRQ. Capping the max_rd_atomic support internally is okay to do as the remaining read/atomic WRs will still be sitting in the SQ. However, for the max_dest_rd_atomic, the driver has to error out as this dictates the IRRQ size and we can't control what the remote side sends. Signed-off-by: Eddie Wai Signed-off-by: Selvin Xavier --- drivers/infiniband/hw/bnxt_re/ib_verbs.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c index 34aa09e..f770737 100644 --- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c +++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c @@ -172,7 +172,7 @@ int bnxt_re_query_device(struct ib_device *ibdev, ib_attr->max_mr = dev_attr->max_mr; ib_attr->max_pd = dev_attr->max_pd; ib_attr->max_qp_rd_atom = dev_attr->max_qp_rd_atom; - ib_attr->max_qp_init_rd_atom = dev_attr->max_qp_rd_atom; + ib_attr->max_qp_init_rd_atom = dev_attr->max_qp_init_rd_atom; ib_attr->atomic_cap = IB_ATOMIC_HCA; ib_attr->masked_atomic_cap = IB_ATOMIC_HCA; @@ -1503,13 +1503,24 @@ int bnxt_re_modify_qp(struct ib_qp *ib_qp, struct ib_qp_attr *qp_attr, if (qp_attr_mask & IB_QP_MAX_QP_RD_ATOMIC) { qp->qplib_qp.modify_flags |= CMDQ_MODIFY_QP_MODIFY_MASK_MAX_RD_ATOMIC; - qp->qplib_qp.max_rd_atomic = qp_attr->max_rd_atomic; + /* Cap the max_rd_atomic to device max */ + qp->qplib_qp.max_rd_atomic = min_t(u32, qp_attr->max_rd_atomic, + dev_attr->max_qp_rd_atom); } if (qp_attr_mask & IB_QP_SQ_PSN) { qp->qplib_qp.modify_flags |= CMDQ_MODIFY_QP_MODIFY_MASK_SQ_PSN; qp->qplib_qp.sq.psn = qp_attr->sq_psn; } if (qp_attr_mask & IB_QP_MAX_DEST_RD_ATOMIC) { + if (qp_attr->max_dest_rd_atomic > + dev_attr->max_qp_init_rd_atom) { + dev_err(rdev_to_dev(rdev), + "max_dest_rd_atomic requested%d is > dev_max%d", + qp_attr->max_dest_rd_atomic, + dev_attr->max_qp_init_rd_atom); + return -EINVAL; + } + qp->qplib_qp.modify_flags |= CMDQ_MODIFY_QP_MODIFY_MASK_MAX_DEST_RD_ATOMIC; qp->qplib_qp.max_dest_rd_atomic = qp_attr->max_dest_rd_atomic;