From patchwork Thu Jun 29 19:28:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Selvin Xavier X-Patchwork-Id: 9817837 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 108E86020A for ; Thu, 29 Jun 2017 19:29:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 044D1212E8 for ; Thu, 29 Jun 2017 19:29:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id ED4AF28615; Thu, 29 Jun 2017 19:29:15 +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 62D37212E8 for ; Thu, 29 Jun 2017 19:29:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753151AbdF2T3O (ORCPT ); Thu, 29 Jun 2017 15:29:14 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:33089 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751988AbdF2T3O (ORCPT ); Thu, 29 Jun 2017 15:29:14 -0400 Received: by mail-wr0-f170.google.com with SMTP id r103so194463061wrb.0 for ; Thu, 29 Jun 2017 12:29:13 -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=PAerR3KjwU98u4vDMxMpAc4PzItNv9TzhuLoAmi6A+c=; b=ekhAgBx6tqzluyhvtJ9r8hsjA3P4PSkqc7RWy/OOTHA3CmypMm7gfB4FIm2zqYZUbS CC4YUud84UElJKArYUl/yIS9V9f/via0+iHo3GmzXHDz7z0L+iiolcwxQxfw2tghpccy vWnWzIdhxANPEtj7xc8clllt7A9uJj6rFtuj8= 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=PAerR3KjwU98u4vDMxMpAc4PzItNv9TzhuLoAmi6A+c=; b=k0BW+IapzWXE+22mUUOLdCQJjG9TD53R6HKJPfFH3o6RNNqsOSutiScQxdk7/T3zjz oIyhj22hKOGxN3TfawpaN/0G5nl8IeZ6App+TNaLnoXJaThqr5Tx61K8iWY9FAA2/ZQx DM0CCmE6R8se40Y6X4YNrQO0uUPQYhjFOmMTLCI3ory2ZaknxChi5ULDOHRh02k91tbJ mg+1ek+69It3mdVAWIaykzLbekrOS0FxXkByrvdurRhHqwXhWO9c/tpwRj8DiWSIxNkT jISy+gSF5kLtS665MjILXVhSWgrVVepluMDoyEGkAvaYcJp7BGrmRYhBPfFqzUKLDydY oIFg== X-Gm-Message-State: AKS2vOzNBVA4Aji5bCldRGXg25s3kEKCYs41Q2JFL1EFcWMJ0lTEfl25 3odDZIdIkacisdu8 X-Received: by 10.223.163.202 with SMTP id m10mr26419494wrb.197.1498764552682; Thu, 29 Jun 2017 12:29:12 -0700 (PDT) Received: from dhcp-10-192-206-197.iig.avagotech.net ([192.19.239.250]) by smtp.gmail.com with ESMTPSA id r40sm6135032wrb.37.2017.06.29.12.29.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 12:29:12 -0700 (PDT) From: Selvin Xavier To: dledford@redhat.com Cc: linux-rdma@vger.kernel.org, Eddie Wai , Selvin Xavier Subject: [PATCH for-next V2 07/13] RDMA/bnxt_re: Fixed the max_rd_atomic support for initiator and destination QP Date: Thu, 29 Jun 2017 12:28:13 -0700 Message-Id: <1498764499-24157-8-git-send-email-selvin.xavier@broadcom.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1498764499-24157-1-git-send-email-selvin.xavier@broadcom.com> References: <1498764499-24157-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 aa96b2c..6629727 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;