From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 05359C47073 for ; Tue, 9 Jan 2024 15:17:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:Message-ID: In-Reply-To:Subject:cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Jcs4QaH9MwrWaUONHzSNLzbfB30+I9+VlAZ7bmxop7I=; b=FA7X8lQk43J4I5 CuNkjN1Hu2h1o1drOOZDhC9cnKOEtbkUY0pA2JRpkpKEak0Xn4vVICDy0G8rUu++NXCO991E+Rl1y SIOGZMT4EAS8/Qn4IBI2usRQv1mvwu42KVkRFsoZSjuI7QfLm9f78gOqRP/Y+WqYsZq2aadF8EgOJ ab4ibdWPBsX6nIKM/Xvs1vEO2F0DD2DQu0u0rU31QBZ6Pp3VN+NYU0a9UpeRwJb3YFCgaKIIp86ZW TkkXkfOoFH7uw+GIaqc+K3Q2NPPxeYH4YbJ3cyriWmvFw5hAFNy1tIb6cvKopSJZ6Qi3Bkpi14Agz xXNmSu7nyEgRmQUa+gTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rNDqC-008dNJ-0y; Tue, 09 Jan 2024 15:16:32 +0000 Received: from relay7-d.mail.gandi.net ([217.70.183.200]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rNDq8-008dLG-2e for linux-arm-kernel@lists.infradead.org; Tue, 09 Jan 2024 15:16:31 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 543ED20002; Tue, 9 Jan 2024 15:16:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1704813386; 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=ssy2NqEQhKlkgPOMZNnArO4w7khdLMgeVZhOT1pVsOI=; b=VFu75ftCyPs7Lt9Z8ASUCZLKtzregIBQ7aO1l9XO0o4PxjAaAZodyeAc62v9jOluNfDemu k3UYeyXIwZv+40VMTA8dbBJ96HLEz1GcKkRFD7hUZ9YA35syoJI0M3P+LZYGF/08ycxnVc hso6sRefCxYy8VW40CxWvbKDZdFfQjw0PJ8q0rbL+a4Y8fcZ+/9tvLsJ8EMPbluacn/FjD GP3DbZjfpODWTrs3T/1J0xL2q6FPFmKGhlQBwYim9+vscLOa2A2cgZWrc9LNHdYZO3S+ma Oo4Ui811n+ADwLMT6aTcnKnAszkX8zPAtIC2pWRcNjiGy9tWl4KoozOfyOye1Q== Date: Tue, 9 Jan 2024 16:16:49 +0100 (CET) From: Romain Gantois To: Vladimir Oltean cc: Romain Gantois , Alexandre Torgue , Jose Abreu , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Maxime Coquelin , Miquel Raynal , Maxime Chevallier , Sylvain Girard , Pascal EBERHARD , Richard Tresidder , Linus Walleij , Florian Fainelli , Andrew Lunn , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org Subject: Re: [PATCH net v3 1/1] net: stmmac: Prevent DSA tags from breaking C In-Reply-To: <20240108143614.ldeizw33o6l7aevi@skbuf> Message-ID: <7afd8717-4b3a-2104-3581-4cf3440be0f8@bootlin.com> References: <20240108130238.j2denbdj3ifasbqi@skbuf> <3c2f6555-53b6-be1c-3d7b-7a6dc95b46fe@bootlin.com> <20240108143614.ldeizw33o6l7aevi@skbuf> MIME-Version: 1.0 X-GND-Sasl: romain.gantois@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240109_071629_131225_63800AA4 X-CRM114-Status: GOOD ( 20.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 8 Jan 2024, Vladimir Oltean wrote: > On Mon, Jan 08, 2024 at 03:23:38PM +0100, Romain Gantois wrote: > > I see, the kernel docs were indeed enlightening on this point. As a side note, > > I've just benchmarked both the "with-inline" and "without-inline" versions. > > First of all, objdump seems to confirm that GCC does indeed follow this pragma > > in this particular case. Also, RX perfs are better with stmmac_has_ip_ethertype > > inlined, but TX perfs are actually consistently worse with this function > > inlined, which could very well be caused by cache effects. > > > > In any case, I think it is better to remove the "inline" pragma as you said. > > I'll do that in v4. > > Are you doing any code instrumentation, or just measuring the results > and deducing what might cause them? > > It might be worth looking at the perf events and seeing what function > consumes the most amount of time. > > CPU_CORE=0 > perf record -e cycles -C $CPU_CORE sleep 10 && perf report > perf record -e cache-misses -C $CPU_CORE sleep 10 && perf report > Unfortunately my hardware doesn't support these performance metrics, but I did manage to do some instrumentation with the ftrace profiler: Same test conditions as before, 10 second iperf3 runs with unfragmented UDP packets. no inline TX average time per call for stmmac_xmit(): 85us average time per call for stmmac_has_ip_ethertype(): 2us no inline RX average time per call for stmmac_napi_poll_rx(): 8142us average time per call for stmmac_has_ip_ethertype(): 2us inline TX: average time per call for stmmac_xmit(): 85us inline RX: average time per call for stmmac_napi_poll_rx(): 8410us It seems like this time, RX performed slightly worse with the function inline. To be honest, I'm starting to doubt the reproducibility of these tests. In any case it seems better to just remove the "inline" and let gcc do the optimizing. Best Regards, -- Romain Gantois, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel