Received: by 10.223.185.116 with SMTP id b49csp819303wrg; Sat, 10 Feb 2018 21:06:52 -0800 (PST) X-Google-Smtp-Source: AH8x227GXKb6v2nQJahRZepjirz8FAyyutkp+se08Od8GM9kAYkGslCcR6WX8O3M3fCmA6bjarAf X-Received: by 10.98.200.133 with SMTP id i5mr7641129pfk.241.1518325612793; Sat, 10 Feb 2018 21:06:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518325612; cv=none; d=google.com; s=arc-20160816; b=y1O/+9EaIhJrJEe6yIxQxmbUHPA8nPfAS9Cb3Ql0O9lIeuWZcDJtl5Z7RDqB/W8H/I kn8rD11W/5G+r3cCC1pH4G0vemo/YDx5qTcT7upx1X8DygiBnhv3T7nX0hguKUaLfwno q0m/zi+c4BCXvz1EgqGu8VLatxoGd370elWzMsVZBe+THWOuDFUc7+fA+O2aoL4/Sx6T aXqEVbS/H+uyFXhbwesjY8Q9DdNuQFYS1hvp3691gd30CjtUtN/9D95q3PoYDvG1SO93 Z9W1LLu0DX4BUZV9U5gLUrYkfedqXvzPw3r/n1PkPtQyphKH7hOYcMMoHXFF+Lm/6l7J LiwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition :arc-authentication-results; bh=Zl2wq5lc1I3zopNre/fUbDcIfcccfpQfGGGDCCZ8/wU=; b=JOLybL8dpT8bvxQuKUeRpb2/0eeSN1DFFl5Pk/4Yf71snzo95br7S3Kxcgg02/kCrc Uw5MfypiV55bkZRqDdOT/suKlhtVssznbU/jJtma9FUWggA39qdf8DYsBp+TQgLy/DEU 37nchWW8Tk2+anZY5EYnvBB8kfpCCC7TsYp4axNl/Eue9yvZrcD+glzQsP9ZXHJN4d33 PrQCw/gPXLP/jzkY1y3V2Ra+/x+cNk91effUGLwHOPu2CeaqB9KireRpA1zyk3MTMUjG TJUoKBcK/0AkA0qOVB6VenZXEWnI1oU/OlYIS3Uok05ChYi7BsmIkcDTRaor9vSfZk9u L4dw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b6-v6si2207124pls.65.2018.02.10.21.06.38; Sat, 10 Feb 2018 21:06:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753897AbeBKFFr (ORCPT + 99 others); Sun, 11 Feb 2018 00:05:47 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:41489 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752674AbeBKEdn (ORCPT ); Sat, 10 Feb 2018 23:33:43 -0500 Received: from [2a02:8011:400e:2:6f00:88c8:c921:d332] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ekjKe-0002hM-Qs; Sun, 11 Feb 2018 04:33:40 +0000 Received: from ben by deadeye with local (Exim 4.90) (envelope-from ) id 1ekjKX-0004UP-W7; Sun, 11 Feb 2018 04:33:33 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Mark Bloch" , "Leon Romanovsky" , "Majd Dibbiny" , "Doug Ledford" Date: Sun, 11 Feb 2018 04:20:06 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.2 37/79] IB/mlx4: Increase maximal message size under UD QP In-Reply-To: X-SA-Exim-Connect-IP: 2a02:8011:400e:2:6f00:88c8:c921:d332 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.2.99-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Mark Bloch commit 5f22a1d87c5315a98981ecf93cd8de226cffe6ca upstream. Maximal message should be used as a limit to the max message payload allowed, without the headers. The ConnectX-3 check is done against this value includes the headers. When the payload is 4K this will cause the NIC to drop packets. Increase maximal message to 8K as workaround, this shouldn't change current behaviour because we continue to set the MTU to 4k. To reproduce; set MTU to 4296 on the corresponding interface, for example: ifconfig eth0 mtu 4296 (both server and client) On server: ib_send_bw -c UD -d mlx4_0 -s 4096 -n 1000000 -i1 -m 4096 On client: ib_send_bw -d mlx4_0 -c UD -s 4096 -n 1000000 -i 1 -m 4096 Fixes: 6e0d733d9215 ("IB/mlx4: Allow 4K messages for UD QPs") Signed-off-by: Mark Bloch Reviewed-by: Majd Dibbiny Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Ben Hutchings --- drivers/infiniband/hw/mlx4/qp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/mlx4/qp.c +++ b/drivers/infiniband/hw/mlx4/qp.c @@ -1047,7 +1047,7 @@ static int __mlx4_ib_modify_qp(struct ib context->mtu_msgmax = (IB_MTU_4096 << 5) | ilog2(dev->dev->caps.max_gso_sz); else - context->mtu_msgmax = (IB_MTU_4096 << 5) | 12; + context->mtu_msgmax = (IB_MTU_4096 << 5) | 13; } else if (attr_mask & IB_QP_PATH_MTU) { if (attr->path_mtu < IB_MTU_256 || attr->path_mtu > IB_MTU_4096) { printk(KERN_ERR "path MTU (%u) is invalid\n",