From patchwork Wed Jun 14 10:26:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Selvin Xavier X-Patchwork-Id: 9786075 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 4E39960325 for ; Wed, 14 Jun 2017 10:27:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4B3A928547 for ; Wed, 14 Jun 2017 10:27:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 402D2285E5; Wed, 14 Jun 2017 10:27:34 +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.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,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 DEBE128547 for ; Wed, 14 Jun 2017 10:27:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751920AbdFNK1d (ORCPT ); Wed, 14 Jun 2017 06:27:33 -0400 Received: from mail-qt0-f178.google.com ([209.85.216.178]:35350 "EHLO mail-qt0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751768AbdFNK1c (ORCPT ); Wed, 14 Jun 2017 06:27:32 -0400 Received: by mail-qt0-f178.google.com with SMTP id w1so199630665qtg.2 for ; Wed, 14 Jun 2017 03:27:32 -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=IIoSWSafia8NRtWmgsWoJaiwzOe7Dz6lhojIkQM8Y9o=; b=ZKGYoOwpbwx5MEbcc3mc5qnXIqclmT3vXgNM7CCMAfw4Y8IAni1jpsbkEj83oJpqti qtJZkkRB81X9i77/MIqgrd2gsjNSE45BsOG1UDaGkMH52QX/ciUTP2/GCQHy32D7fLpR WVImrUmvipHr8soQSKM1JPqhf9fbx5D5Ipxh8= 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=IIoSWSafia8NRtWmgsWoJaiwzOe7Dz6lhojIkQM8Y9o=; b=KOq6ALodZCMIIRgAkEup5McmcevglqMMufWOGpfbHej2Jdf8WSE4PagaGS6O28cGuR Q5aGnQkjw3pJTNXNeLLhz0hK/d6yZs7PhyUooUnvLeof7ouTtPAH5bgB35kgz5Ol4rkA DTWFXqsr7Cs/Vc3WL8mjreLnfLdWoy06Bz88ScUOsUy4SFpZ52hD9ZWr/hV9Ya5iP87Y BrlV723rRnyNEfk/JirJA4nYscdULIuEXOOLerqyc/PEJo7YmHZrJnChVwPlzS3zNyfn f+KO2uNA/drv5a2aofHMKYGjCA2tCl7j2gXnGaMigqMf+JzUy9clOW45NuKj3JjcRe/Z UzsQ== X-Gm-Message-State: AKS2vOwtQh1O81t48sbs2ljP3HEUlNLnnqbP8CyTBJ5R7VnO0yNyROuu 5tbjJV/ITfNj+Lp/ X-Received: by 10.237.44.101 with SMTP id f92mr5866547qtd.150.1497436051561; Wed, 14 Jun 2017 03:27:31 -0700 (PDT) Received: from dhcp-10-192-206-197.iig.avagotech.net ([192.19.239.250]) by smtp.gmail.com with ESMTPSA id o49sm285065qta.34.2017.06.14.03.27.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jun 2017 03:27:31 -0700 (PDT) From: Selvin Xavier To: dledford@redhat.com Cc: linux-rdma@vger.kernel.org, Eddie Wai , Selvin Xavier Subject: [PATCH V5 for-next 12/14] RDMA/bnxt_re: Fixed the max_rd_atomic support for initiator and destination QP Date: Wed, 14 Jun 2017 03:26:33 -0700 Message-Id: <1497435995-20480-13-git-send-email-selvin.xavier@broadcom.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1497435995-20480-1-git-send-email-selvin.xavier@broadcom.com> References: <1497435995-20480-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 841cf3b..6b0f0cf 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; @@ -1497,13 +1497,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;