From patchwork Wed May 17 09:19:48 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Selvin Xavier X-Patchwork-Id: 9730523 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 6C6C7602DB for ; Wed, 17 May 2017 09:21:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 67F3927C2D for ; Wed, 17 May 2017 09:21:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5D11628718; Wed, 17 May 2017 09:21:45 +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 F1E6327C2D for ; Wed, 17 May 2017 09:21:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754075AbdEQJV0 (ORCPT ); Wed, 17 May 2017 05:21:26 -0400 Received: from mail-qt0-f171.google.com ([209.85.216.171]:33728 "EHLO mail-qt0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753762AbdEQJVX (ORCPT ); Wed, 17 May 2017 05:21:23 -0400 Received: by mail-qt0-f171.google.com with SMTP id t26so4553068qtg.0 for ; Wed, 17 May 2017 02:21:22 -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=mNk1wRgj2VxS6f82v2V2pDE9TTQLtYvhyLna9+CCHiQ=; b=Z/rVViPoatLOpeD80Vk+HKaFIvab6VpLaPey+pYmoaIu3m3cWdTHbEvywKLqrALLSR FsaR0UsJ3nRrEg4V+EULwwuEZ57nNpD69/fmyoLYkf8lkQmNhRbt4tnh1ovJNx2nDBf9 v7SsvOkwHwAdFzmKKuLhGyDwJvIRWTOok/OSc= 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=mNk1wRgj2VxS6f82v2V2pDE9TTQLtYvhyLna9+CCHiQ=; b=okQ/j2PubGQsvQXTcW17ZMz9wCTAVDMPDWX3j2oVXHYihD9+D8R5EBIwORYPEbjBZu 5zIF8o10aHdaOMckGEtTfF7TVcLOp7REryP13eznkYw6C2vEakJH0AEQ6HbYqXLf9GC4 GuagtzyZRicJiY/ryaXFj2zgjxFaiLI9fhdf2JVNj4dZh2C+zg1p2trlaBjJSy4ba1AQ bGF1PIe969x6H7hMcj3tN5um90dW5hV2nrFcZcS9IMtwW/ola7bUmD9/OMkjDpkcpK5z HxIPuCcvyCh68sNJJZm79u3Nj2HQu8EC+aA0f5gpr6jGrrZTyi8tVPcR650XoF9yMOnV dJmw== X-Gm-Message-State: AODbwcDSZ0oaKUAgcagQQMCOg9zfjXHkoK1fxQ99GSkkubeJV3y23+RG XljmzNhcxGMxu36B X-Received: by 10.200.45.121 with SMTP id o54mr1910578qta.43.1495012882117; Wed, 17 May 2017 02:21:22 -0700 (PDT) Received: from dhcp-10-192-206-197.iig.avagotech.net ([192.19.239.250]) by smtp.gmail.com with ESMTPSA id t136sm998431qke.40.2017.05.17.02.21.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 02:21:21 -0700 (PDT) From: Selvin Xavier To: dledford@redhat.com Cc: linux-rdma@vger.kernel.org, Eddie Wai , Selvin Xavier Subject: [PATCH V2 for-next 12/15] RDMA/bnxt_re: Fixed the max_rd_atomic support for initiator and destination QP Date: Wed, 17 May 2017 02:19:48 -0700 Message-Id: <1495012791-5053-13-git-send-email-selvin.xavier@broadcom.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1495012791-5053-1-git-send-email-selvin.xavier@broadcom.com> References: <1495012791-5053-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 fb09e98..aa3d2e6 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; @@ -1502,13 +1502,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;