Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp21964ybk; Fri, 8 May 2020 17:18:22 -0700 (PDT) X-Google-Smtp-Source: APiQypLkTNVMK3dARNDnevTG4Li9caAMGFlo50Fbh7QCVQuEfUGyml59+dkAJE8Wejk8EHjdcOWE X-Received: by 2002:a17:907:9488:: with SMTP id dm8mr4117889ejc.230.1588983502076; Fri, 08 May 2020 17:18:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588983502; cv=none; d=google.com; s=arc-20160816; b=geeyCPtk500xfGtJFi9ubuJNaBtAQceLIbpTj23Q+m1Z4msNDSQw3ElYV6B3PZw7f5 evME8D3M+KlOXKsjMZnFcqOP5yiW+M0ABaax/A+iayhWMCLFgI7PKYQBX8QR3SJJ2Bn0 qF/u3do5doe9qtFlscX/I0SIMM1M+1swcaWjKFuNLbvOpsu1Bfe1644FO1ZuWIxmIs+l 0BgICpNFHUOcq06V1XM2fIgIrQqycwaPbrPSSHAHG16LDeLFLH2O6Mn5hbEDbsahXiKE GC2Sz7JagZMTETKmj2jCo7vUkpo8VfoAUSOQ9iVyPag5lXSXHkuMOr+Jaa33CiUOV8ZN G6jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=ZhMKYaxcr11NMRkCgTBjG7GpLbTFZxzwIgvmF68ljDw=; b=KUlPK4rATEA40RHuopgpBlpSh0htRgzmHEwbq7qMWPVBlfnUyLlNuQeUMb9jZ1COqH w8bq9J+FJ1AiXFRWIhKdDG6Eoxg2ruTHKIU1trvw4rFFDdeCjlxcS/STTFX63hts4C3w KFtnXPcprHI/tWJ07onHyb/1bJIEmcAiQRZgYYNMreTQlI3Ve7a1mOwaayq8JwIAfom0 FhDnREfmsU+E7Mst6yhqnqW5EiCqf+S5nZJXdpZwW/Vv1uTyFNLjSQEKVClf9y8THHJa nHaBhrGP1aBcG00k6F2NM6PdzFAbu/uGw1PrpN3NsBPqm70Xg+xeQO4QSmM4urDb2Vmu WRFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Sv0jBOSA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r21si2057868eju.300.2020.05.08.17.17.59; Fri, 08 May 2020 17:18:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Sv0jBOSA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728510AbgEIANt (ORCPT + 99 others); Fri, 8 May 2020 20:13:49 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:32629 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728493AbgEIANr (ORCPT ); Fri, 8 May 2020 20:13:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588983226; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZhMKYaxcr11NMRkCgTBjG7GpLbTFZxzwIgvmF68ljDw=; b=Sv0jBOSAyOqQ+aXqJ+FSQz4fnEp+6fxUun63p6CIMZUg6fDfflJhAZ1L3lxiE+zdkRYH8r O5wMrkUAlC0OJJ/k4XdljVXriiKlhzivBLv52Kd+R8lr4bHzjpehygA5Tr9J5GEzdG1fLp MC7ioT/YNNYL0MpFSv2QSfVUsgDBdrU= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-163-LGrxMzoiOamt2ZVTSQchzA-1; Fri, 08 May 2020 20:13:34 -0400 X-MC-Unique: LGrxMzoiOamt2ZVTSQchzA-1 Received: by mail-ej1-f70.google.com with SMTP id bz19so1341539ejc.18 for ; Fri, 08 May 2020 17:13:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZhMKYaxcr11NMRkCgTBjG7GpLbTFZxzwIgvmF68ljDw=; b=j8/TKdG77bn3tBXgZS59NLfeq3a3atHAm6lffK6bfc1/AlVH3eTaV0L8Mpgt0z5M2I TS/DfNXMf8Qg2I+UoTh9WVf9QpMqd0i0CmsQyMdmSaGtDYZBe5OEPpn0azQxaZ5SYsPP nKJtxCojUH/9Zr/566GARtzcOqDWqG6Gj8hPr1vnWE0+2ZS/p+yGHsVXEqrZGh/kcFCK 4lFYZs7FfEY2BY3k2qFLnjrtq92q0krdpmDrhSSqqYljTM+oNxjR7M0/Rrscba9/Rzmg klNMjp6MoeqgwMBrc06uE6YnlztnK4erDLT828Pt3ovgUQehZYk5BnHtdqE4uoQ5JvY8 gGPg== X-Gm-Message-State: AGi0PuauxbKn7QtV1BuzsihFVdyY4s25ZzpSTSt5NdNXIzGDc7oX/hYw iS+n/xdnkNox5iMIkYk4pq1RH5nL//Ulc7SuT7rKMHdu8d4svU9DQ0gevnMpvkvWc3f55LaBLHb NKYdJ6HVsahCERIUeDAmNun0uG01ruahflb1pDOKk X-Received: by 2002:a17:906:328c:: with SMTP id 12mr3850930ejw.69.1588983213651; Fri, 08 May 2020 17:13:33 -0700 (PDT) X-Received: by 2002:a17:906:328c:: with SMTP id 12mr3850919ejw.69.1588983213332; Fri, 08 May 2020 17:13:33 -0700 (PDT) MIME-Version: 1.0 References: <20190524100554.8606-1-maxime.chevallier@bootlin.com> <20190524100554.8606-4-maxime.chevallier@bootlin.com> <20200423170003.GT25745@shell.armlinux.org.uk> In-Reply-To: <20200423170003.GT25745@shell.armlinux.org.uk> From: Matteo Croce Date: Sat, 9 May 2020 02:12:57 +0200 Message-ID: Subject: Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to handle RSS tables To: "David S . Miller" Cc: Maxime Chevallier , netdev , LKML , Antoine Tenart , Thomas Petazzoni , gregory.clement@bootlin.com, miquel.raynal@bootlin.com, Nadav Haklai , Stefan Chulski , Marcin Wojtas , Linux ARM , Russell King - ARM Linux admin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 23, 2020 at 7:00 PM Russell King - ARM Linux admin wrote: > > On Tue, Apr 14, 2020 at 01:43:02AM +0200, Matteo Croce wrote: > > On Tue, Apr 14, 2020 at 1:21 AM Maxime Chevallier > > wrote: > > > > > > The PPv2 controller has 8 RSS tables that are shared across all ports on > > > a given PPv2 instance. The previous implementation allocated one table > > > per port, leaving others unused. > > > > > > By using RSS contexts, we can make use of multiple RSS tables per > > > port, one being the default table (always id 0), the other ones being > > > used as destinations for flow steering, in the same way as rx rings. > > > > > > This commit introduces RSS contexts management in the PPv2 driver. We > > > always reserve one table per port, allocated when the port is probed. > > > > > > The global table list is stored in the struct mvpp2, as it's a global > > > resource. Each port then maintains a list of indices in that global > > > table, that way each port can have it's own numbering scheme starting > > > from 0. > > > > > > One limitation that seems unavoidable is that the hashing parameters are > > > shared across all RSS contexts for a given port. Hashing parameters for > > > ctx 0 will be applied to all contexts. > > > > > > Signed-off-by: Maxime Chevallier > > > > Hi all, > > > > I noticed that enabling rxhash blocks the RX on my Macchiatobin. It > > works fine with the 10G ports (the RX rate goes 4x up) but it > > completely kills the gigabit interface. > > > > # 10G port > > root@macchiatobin:~# iperf3 -c 192.168.0.2 > > Connecting to host 192.168.0.2, port 5201 > > [ 5] local 192.168.0.1 port 42394 connected to 192.168.0.2 port 5201 > > [ ID] Interval Transfer Bitrate Retr Cwnd > > [ 5] 0.00-1.00 sec 941 MBytes 7.89 Gbits/sec 4030 250 KBytes > > [ 5] 1.00-2.00 sec 933 MBytes 7.82 Gbits/sec 4393 240 KBytes > > root@macchiatobin:~# ethtool -K eth0 rxhash on > > root@macchiatobin:~# iperf3 -c 192.168.0.2 > > Connecting to host 192.168.0.2, port 5201 > > [ 5] local 192.168.0.1 port 42398 connected to 192.168.0.2 port 5201 > > [ ID] Interval Transfer Bitrate Retr Cwnd > > [ 5] 0.00-1.00 sec 860 MBytes 7.21 Gbits/sec 428 410 KBytes > > [ 5] 1.00-2.00 sec 859 MBytes 7.20 Gbits/sec 185 563 KBytes > > > > # gigabit port > > root@macchiatobin:~# iperf3 -c turbo > > Connecting to host turbo, port 5201 > > [ 5] local 192.168.85.42 port 45144 connected to 192.168.85.6 port 5201 > > [ ID] Interval Transfer Bitrate Retr Cwnd > > [ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 0 407 KBytes > > [ 5] 1.00-2.00 sec 112 MBytes 942 Mbits/sec 0 428 KBytes > > root@macchiatobin:~# ethtool -K eth2 rxhash on > > root@macchiatobin:~# iperf3 -c turbo > > iperf3: error - unable to connect to server: Resource temporarily unavailable > > > > I've bisected and it seems that this commit causes the issue. I tried > > to revert it on nex-next as a second test, but the code has changed a > > lot much since, generating too much conflicts. > > Can you have a look into this? > > This behaviour on eth2 is confirmed here on v5.6. Turning on rxhash > appears to prevent eth2 working. > > Maxime, please look into this regression, thanks. > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up > Hi, What do you think about temporarily disabling it like this? --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -5775,7 +5775,8 @@ static int mvpp2_port_probe(struct platform_device *pdev, NETIF_F_HW_VLAN_CTAG_FILTER; if (mvpp22_rss_is_supported()) { - dev->hw_features |= NETIF_F_RXHASH; + if (port->phy_interface != PHY_INTERFACE_MODE_SGMII) + dev->hw_features |= NETIF_F_RXHASH; dev->features |= NETIF_F_NTUPLE; } David, is this "workaround" too bad to get accepted? Bye, -- Matteo Croce per aspera ad upstream