From patchwork Mon Oct 9 13:34:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Ledford X-Patchwork-Id: 9993307 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 9677860244 for ; Mon, 9 Oct 2017 13:34:52 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8703522B27 for ; Mon, 9 Oct 2017 13:34:52 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7B41628528; Mon, 9 Oct 2017 13:34:52 +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.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI 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 E98C822B27 for ; Mon, 9 Oct 2017 13:34:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754324AbdJINet (ORCPT ); Mon, 9 Oct 2017 09:34:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52354 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751621AbdJINef (ORCPT ); Mon, 9 Oct 2017 09:34:35 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 18F728046E; Mon, 9 Oct 2017 13:34:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 18F728046E Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dledford@redhat.com Received: from linux-ws.xsintricity.com (ovpn-123-108.rdu2.redhat.com [10.10.123.108]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8B55818796; Mon, 9 Oct 2017 13:34:34 +0000 (UTC) Message-ID: <1507556073.46071.27.camel@redhat.com> Subject: Re: Is ib_mtu iboe_get_mtu() slightly off? From: Doug Ledford To: Parav Pandit , Roland Dreier , "linux-rdma@vger.kernel.org" Date: Mon, 09 Oct 2017 09:34:33 -0400 In-Reply-To: References: Organization: Red Hat, Inc. Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 09 Oct 2017 13:34:35 +0000 (UTC) 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 On Thu, 2017-09-21 at 02:20 +0000, Parav Pandit wrote: > > From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma- > > owner@vger.kernel.org] On Behalf Of Roland Dreier > > Sent: Wednesday, September 20, 2017 7:39 PM > > To: linux-rdma@vger.kernel.org > > Subject: Is ib_mtu iboe_get_mtu() slightly off? > > > > We have: > > > > static inline enum ib_mtu iboe_get_mtu(int mtu) { > > /* > > * reduce IB headers from effective IBoE MTU. 28 stands for > > * atomic header which is the biggest possible header after > > BTH > > */ > > mtu = mtu - IB_GRH_BYTES - IB_BTH_BYTES - 28; > > ... > > > > 28 bytes is the size of the AtomicETH header. But couldn't we have > > a packet > > with both AtomicETH and XRCETH (4 more bytes)? > > XRCETH + AtomicETH is possible. > Additionally I guess 4 bytes of ICRC is missing too in calculation. Since no one rolled a patch for this, I did. commit 7107ee2ea38fb52ffe81be054657e90863ebe8ab (HEAD -> k.o/for-next) Author: Doug Ledford Date: Mon Oct 9 09:26:47 2017 -0400 RDMA/core: Fix iboe_get_mtu size calculation We mistakenly used the size of the largest header possible after BTH_BYTES without considering that this largest header might actually be in combination with a few select other headers. So, increase the size of the largest header number to be the size of the largest possible combination of headers instead of just the single largest header. Fixes: 3c86aa70bf67 (RDMA/cm: Add RDMA CM support for IBoE devices) Reported-by: Roland Drier Reported-by: Parav Pandit Signed-off-by: Doug Ledford diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h index ec5008cf5d51..45a03c514437 100644 --- a/include/rdma/ib_addr.h +++ b/include/rdma/ib_addr.h @@ -245,10 +245,11 @@ static inline void rdma_addr_set_dgid(struct rdma_dev_addr *dev_addr, union ib_g static inline enum ib_mtu iboe_get_mtu(int mtu) { /* - * reduce IB headers from effective IBoE MTU. 28 stands for - * atomic header which is the biggest possible header after BTH + * reduce IB headers from effective IBoE MTU. 36 stands for + * AtomicETH + XRCETH + ICRC, which is the biggest header + * combination possible after BTH */ - mtu = mtu - IB_GRH_BYTES - IB_BTH_BYTES - 28; + mtu = mtu - IB_GRH_BYTES - IB_BTH_BYTES - 36; if (mtu >= ib_mtu_enum_to_int(IB_MTU_4096)) return IB_MTU_4096;