Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp482697ybk; Sat, 9 May 2020 08:36:21 -0700 (PDT) X-Google-Smtp-Source: APiQypKriwT4IlAWHiJyw1R3vO2coOK5t6+44kpGOvKkQ5UwEJpM0IsQJkQKI+pqxENssULnJQrk X-Received: by 2002:aa7:c744:: with SMTP id c4mr2587301eds.241.1589038581604; Sat, 09 May 2020 08:36:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589038581; cv=none; d=google.com; s=arc-20160816; b=LZLerZ8rK+m30HNWd/UkiQZrcjauarrDnJtfowi8B/0kQWO8RCooVMShpk1ywDYjAY W5rtilFH5O0Y7Ok+BVD91ZQejFIXpA1eksb3Dut2EKJwlFjAujAekeD5x4u4LL3oNNua XqbnHt5Mb6TJLeo4LfZTz0FWG2Y6nVgwEL6epAfJ39mtXLclujibfxtoX3RQOEQl8zdY pCNGMWKjAU9t8hdWY2EWxq2KtZdHaXstia6CSnP9/6oBVYkvlYEU877iIN7tyVqkmqaB Txemar8WUYCaEj4X6hAt0J2kUhhp45sLYYp+4RmLNk5zAhyMI2jo9vZMPLfCHSmPOzHh ztOg== 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=/9k5BNMmUns9N4aHfKaKHFFWzY7YhzMz20SuR2GCOTs=; b=zsAA5RyveGr4GlKKHE6jQUj9v6pqwxUUEf0AotjPV+JIe+ufNJtV6rNZDb+EQDMxrx CHTPvtLW9UW7oQKsHIAojax1FRChyHzlqsfErBtSgZNmwwzWc6z22r6Wyh77HPdVB6zp Gdv+F1b12zHzy5wkKi271frwhO2PQUWbPcp8mP75htHqsZ4ZA2fklGDScBiAQFXxFxiq RjDEjAvl4Hz4vc0HtfQELNkNnqUn7Gaxkvt8JPBJlcEQ8bCMXX5DJ+YWaANiBi2OsJPL ZhsLEMMxMddIbU3l2zZr1Lu36W+HLl2NQwS1HE1JgURArgJPPRJHYXH/3s3kKzK2+af4 CHgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ix+nhEVm; 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 n8si2885937edb.372.2020.05.09.08.35.57; Sat, 09 May 2020 08:36:21 -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=ix+nhEVm; 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 S1727998AbgEIPcQ (ORCPT + 99 others); Sat, 9 May 2020 11:32:16 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:32623 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727105AbgEIPcP (ORCPT ); Sat, 9 May 2020 11:32:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589038333; 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=/9k5BNMmUns9N4aHfKaKHFFWzY7YhzMz20SuR2GCOTs=; b=ix+nhEVm8OpR7UTPBEb2SeHF7bKtlH0oM5/8IRGPlBlvBsoVDhnV+pYPcJ0IKDUtFlgeJZ riKhmU4ngXGC2NvvICexcwwMl4b6JCe97+FwdBsDUmxQXirhxV3/Tmzuft2sh/rxyih86e pexcFs/aPdc9/qX/lrff2+1VoV6QIl4= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-453-L8njlN-qO-Kba3Xu6IFZEw-1; Sat, 09 May 2020 11:32:06 -0400 X-MC-Unique: L8njlN-qO-Kba3Xu6IFZEw-1 Received: by mail-ed1-f70.google.com with SMTP id y66so1775572ede.19 for ; Sat, 09 May 2020 08:32:06 -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=/9k5BNMmUns9N4aHfKaKHFFWzY7YhzMz20SuR2GCOTs=; b=KbjORSppU1MelB/ojRcEerpqLBUvhwbID13f/pS3MVChjzq6ybcWCXK4STEm/lycWP g8j9oBKJ/gAbXX77rZ/Kjigwbdz8vRXRrzKjLmWzKySOez3qV5eIRnmQ776OalV61yBM N2/4Ol/7vi/I68gk5PMiOWKDlM2fPnQrd8emkUwz7e5bSvbzmVcrJEQFfJyX1aSM7QBc Nlfl/vahzXwniadL9hdW/6Ec7GGgXv6ym+XqzlmcVNgTbCnGT78nGyy0uW8+jTn1JXQE pFoyAe8dZG+6APPh89nQtYNI0OPqwG3rTYaeu6knhqeWmD7ZyXGqYxVniz+57jrriN/M Jrsw== X-Gm-Message-State: AGi0PuZNPhzBF4UvOpa/wsHpe5BHap6Z/CAmO81QP3UHwzVnEUpKWoI6 +pE5I0RJIV14No5bj0gBuudHR8edMlHsW+EgQ4UzqfKPR2qGPnbyskJtGx4j9EcRjoI/Hwf4XHd WttbU1B6EavB+WhnT9isz3Ntn/YPJTAcVE/RDPpcV X-Received: by 2002:aa7:d513:: with SMTP id y19mr6798468edq.367.1589038325044; Sat, 09 May 2020 08:32:05 -0700 (PDT) X-Received: by 2002:aa7:d513:: with SMTP id y19mr6798455edq.367.1589038324809; Sat, 09 May 2020 08:32:04 -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> <20200509114518.GB1551@shell.armlinux.org.uk> <20200509135105.GE1551@shell.armlinux.org.uk> <20200509144845.GF1551@shell.armlinux.org.uk> In-Reply-To: <20200509144845.GF1551@shell.armlinux.org.uk> From: Matteo Croce Date: Sat, 9 May 2020 17:31:29 +0200 Message-ID: Subject: Re: [EXT] Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to handle RSS tables To: Russell King - ARM Linux admin Cc: Antoine Tenart , netdev , "gregory.clement@bootlin.com" , LKML , Maxime Chevallier , Nadav Haklai , Thomas Petazzoni , "miquel.raynal@bootlin.com" , Stefan Chulski , Marcin Wojtas , "David S . Miller" , Linux ARM 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 Sat, May 9, 2020 at 4:49 PM Russell King - ARM Linux admin wrote: > > On Sat, May 09, 2020 at 02:51:05PM +0100, Russell King - ARM Linux admin wrote: > > On Sat, May 09, 2020 at 03:14:05PM +0200, Matteo Croce wrote: > > > On Sat, May 9, 2020 at 1:45 PM Russell King - ARM Linux admin > > > wrote: > > > > > > > > On Sat, May 09, 2020 at 11:15:58AM +0000, Stefan Chulski wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Matteo Croce > > > > > > Sent: Saturday, May 9, 2020 3:13 AM > > > > > > 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 > > > > > > > > > > > > Subject: [EXT] Re: [PATCH net-next 3/5] net: mvpp2: cls: Use RSS contexts to > > > > > > handle RSS tables > > > > > > > > > > > > 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? > > > > > > > > > > Not sure that RSS related to physical interface(SGMII), better just remove NETIF_F_RXHASH as "workaround". > > > > > > > > Hmm, I'm not sure this is the right way forward. This patch has the > > > > effect of disabling: > > > > > > > > d33ec4525007 ("net: mvpp2: add an RSS classification step for each flow") > > > > > > > > but the commit you're pointing at which caused the regression is: > > > > > > > > 895586d5dc32 ("net: mvpp2: cls: Use RSS contexts to handle RSS tables") > > > > > > > > > > > > > > Hi, > > > > > > When git bisect pointed to 895586d5dc32 ("net: mvpp2: cls: Use RSS > > > contexts to handle RSS tables"), which was merged > > > almost an year after d33ec4525007 ("net: mvpp2: add an RSS > > > classification step for each flow"), so I assume that between these > > > two commits either the feature was working or it was disable and we > > > didn't notice > > > > > > Without knowing what was happening, which commit should my Fixes tag point to? > > > > Let me make sure that I get this clear: > > > > - Prior to 895586d5dc32, you can turn on and off rxhash without issue > > on any port. > > - After 895586d5dc32, turning rxhash on eth2 prevents reception. > > > > Prior to 895586d5dc32, with rxhash on, it looks like hashing using > > CRC32 is supported but only one context. So, if it's possible to > > enable rxhash on any port on the mcbin without 895586d5dc32, and the > > port continues to work, I'd say the bug was introduced by > > 895586d5dc32. > > > > Of course, that would be reinforced if there was a measurable > > difference in performance due to rxhash on each port. > > I've just run this test, but I can detect no difference in performance > with or without 895586d5dc32 on eth0 or eth2 on the mcbin (apart from > eth2 stopping working with 895586d5dc32 applied.) I tested this by > reverting almost all changes to the mvpp2 driver between 5.6 and that > commit. > > That's not too surprising; I'm using my cex7 platform with the Mellanox > card in for one end of the 10G link, and that platform doesn't seem to > be able to saturdate a 10G link - it only seems to manage around 4Gbps. > > -- > 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 > Well it depends on the traffic type. I used to generate 5k flows with T-Rex and an Intel X710 card. This way t-rex changes the UDP port of every packet: root@macchiatobin:~# tcpdump -tnni eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes IP 16.0.0.18.9874 > 48.0.0.81.2001: UDP, length 18 IP 16.0.0.248.56289 > 48.0.192.56.2001: UDP, length 18 IP 16.0.0.154.44965 > 48.0.128.26.2001: UDP, length 18 IP 16.0.0.23.31363 > 48.0.0.86.2001: UDP, length 18 IP 16.0.0.192.1674 > 48.0.192.63.2001: UDP, length 18 IP 16.0.0.155.62370 > 48.0.128.27.2001: UDP, length 18 IP 16.0.0.30.22126 > 48.0.0.93.2001: UDP, length 18 IP 16.0.0.195.51329 > 48.0.192.66.2001: UDP, length 18 IP 16.0.0.160.18323 > 48.0.128.32.2001: UDP, length 18 IP 16.0.0.199.55413 > 48.0.192.70.2001: UDP, length 18 And here RX hash gives a huge performance gain. root@macchiatobin:~# utraf eth0 tx: 0 bps 0 pps rx: 425.5 Mbps 886.5 Kpps tx: 0 bps 0 pps rx: 426.0 Mbps 887.6 Kpps tx: 0 bps 0 pps rx: 425.3 Mbps 886.1 Kpps tx: 0 bps 0 pps rx: 425.2 Mbps 885.8 Kpps root@macchiatobin:~# ethtool -K eth0 rxhash on root@macchiatobin:~# utraf eth0 tx: 0 bps 0 pps rx: 1595 Mbps 3323 Kpps tx: 0 bps 0 pps rx: 1593 Mbps 3319 Kpps tx: 0 bps 0 pps rx: 1595 Mbps 3323 Kpps tx: 0 bps 0 pps rx: 1594 Mbps 3320 Kpps utraf is just a tool which reads netlink statistics, packets are dropped with a tc rule. Regards, -- Matteo Croce per aspera ad upstream