Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3825986pxt; Tue, 10 Aug 2021 12:12:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzur1TeMVH20mBCn9iAto/kmXw3sWCOaCCYdgdKU+5JJcvv7Qsqxz6q4n8VPTdMO8OzJRXT X-Received: by 2002:a05:6402:cae:: with SMTP id cn14mr6724620edb.31.1628622728391; Tue, 10 Aug 2021 12:12:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628622728; cv=none; d=google.com; s=arc-20160816; b=IB7d5IMGIqJOnFHKAwtf2tczF4NaSNM6DiuQM/grnKV545daDBTHqnfyrfRCSiNcS1 7dq/v0X22nIEJSL7sDIFW+c+RIpwQh/1FFgrhldpyVwD+qy90ReaYJrlIKO+WGiAbmeJ afJpdetqEGkUReBMqVmLLdB6vHHherkDjyi1QuKiewLMoBFbNBSmzZiK/z5zWCNzghjz q7dhq0BYSCnkt9ItI84FeGQ+5XpyXGmxAE1CPm9z+xAR+vOZNxCu2GJxiqXnBWwxdmYS TonM+CbqGHkUM2JmbEy/46wLtCQkPQjam9SHhVW1waYkj+W1FU5ye6r0jQNLpkcfkeYE JAUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date; bh=r3KT9JRQnkKjk8p52HYKcjZ8utQXgWEpGLyAKDDjhj8=; b=jSluQVAoAgpjmLd8LgNbUK/w4p7agQw4ZVB4e9QopxwEC/d/NKMVNVQCMDE3JVDnmM GIhl1p3DPeXeTyb79TfiezdNwghQsohQKK+2R75Ew5Pg95BdKaIP1P5vkHbi9zVnNjId NxNIdj5DkV6bOG3UvL4ApIoLPXqaPLrN7DofOK5/Jm16u7zPXviFehV6xRoGoqhr8kQk D8W/+VawnEcnqcU839KfxcacPZjUNNOCWuUcPIB3kkv/0t35GxRPZ9m6DwOJguTMiL7T xV63KQuj+1DxdFtUen89iw4YsNdkuUWLj+VCw2Z1F4t5X2VvwFrXo5+r3WHjVqE++AM5 zZPw== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hp30si4273501ejc.610.2021.08.10.12.11.43; Tue, 10 Aug 2021 12:12:08 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231789AbhHJTIN (ORCPT + 99 others); Tue, 10 Aug 2021 15:08:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:37320 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229788AbhHJTIM (ORCPT ); Tue, 10 Aug 2021 15:08:12 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6ED6960F38; Tue, 10 Aug 2021 19:07:50 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mDX6K-0049YK-Cu; Tue, 10 Aug 2021 20:07:48 +0100 Date: Tue, 10 Aug 2021 20:07:47 +0100 Message-ID: <871r71azjw.wl-maz@kernel.org> From: Marc Zyngier To: Matteo Croce Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Giuseppe Cavallaro , Alexandre Torgue , "David S. Miller" , Jakub Kicinski , Palmer Dabbelt , Paul Walmsley , Drew Fustini , Emil Renner Berthing , thierry reding , Jon Hunter , Will Deacon Subject: Re: [PATCH net-next] stmmac: align RX buffers In-Reply-To: <20210614022504.24458-1-mcroce@linux.microsoft.com> References: <20210614022504.24458-1-mcroce@linux.microsoft.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: mcroce@linux.microsoft.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, peppe.cavallaro@st.com, alexandre.torgue@foss.st.com, davem@davemloft.net, kuba@kernel.org, palmer@dabbelt.com, paul.walmsley@sifive.com, drew@beagleboard.org, kernel@esmil.dk, thierry.reding@gmail.com, jonathanh@nvidia.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, [adding Thierry, Jon and Will to the fun] On Mon, 14 Jun 2021 03:25:04 +0100, Matteo Croce wrote: > > From: Matteo Croce > > On RX an SKB is allocated and the received buffer is copied into it. > But on some architectures, the memcpy() needs the source and destination > buffers to have the same alignment to be efficient. > > This is not our case, because SKB data pointer is misaligned by two bytes > to compensate the ethernet header. > > Align the RX buffer the same way as the SKB one, so the copy is faster. > An iperf3 RX test gives a decent improvement on a RISC-V machine: > > before: > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 733 MBytes 615 Mbits/sec 88 sender > [ 5] 0.00-10.01 sec 730 MBytes 612 Mbits/sec receiver > > after: > [ ID] Interval Transfer Bitrate Retr > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender > [ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec receiver > > And the memcpy() overhead during the RX drops dramatically. > > before: > Overhead Shared O Symbol > 43.35% [kernel] [k] memcpy > 33.77% [kernel] [k] __asm_copy_to_user > 3.64% [kernel] [k] sifive_l2_flush64_range > > after: > Overhead Shared O Symbol > 45.40% [kernel] [k] __asm_copy_to_user > 28.09% [kernel] [k] memcpy > 4.27% [kernel] [k] sifive_l2_flush64_range > > Signed-off-by: Matteo Croce This patch completely breaks my Jetson TX2 system, composed of 2 Nvidia Denver and 4 Cortex-A57, in a very "funny" way. Any significant amount of traffic result in all sort of corruption (ssh connections get dropped, Debian packages downloaded have the wrong checksums) if any Denver core is involved in any significant way (packet processing, interrupt handling). And it is all triggered by this very change. The only way I have to make it work on a Denver core is to route the interrupt to that particular core and taskset the workload to it. Any other configuration involving a Denver CPU results in some sort of corruption. On their own, the A57s are fine. This smells of memory ordering going really wrong, which this change would expose. I haven't had a chance to dig into the driver yet (it took me long enough to bisect it), but if someone points me at what is supposed to synchronise the DMA when receiving an interrupt, I'll have a look. Thanks, M. > --- > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h > index b6cd43eda7ac..04bdb3950d63 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h > @@ -338,9 +338,9 @@ static inline bool stmmac_xdp_is_enabled(struct stmmac_priv *priv) > static inline unsigned int stmmac_rx_offset(struct stmmac_priv *priv) > { > if (stmmac_xdp_is_enabled(priv)) > - return XDP_PACKET_HEADROOM; > + return XDP_PACKET_HEADROOM + NET_IP_ALIGN; > > - return 0; > + return NET_SKB_PAD + NET_IP_ALIGN; > } > > void stmmac_disable_rx_queue(struct stmmac_priv *priv, u32 queue); > -- > 2.31.1 > > -- Without deviation from the norm, progress is not possible.