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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6EA1C4332F for ; Mon, 19 Dec 2022 07:50:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231529AbiLSHuL (ORCPT ); Mon, 19 Dec 2022 02:50:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41578 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229957AbiLSHuJ (ORCPT ); Mon, 19 Dec 2022 02:50:09 -0500 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90C836166; Sun, 18 Dec 2022 23:50:08 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 581C95C012D; Mon, 19 Dec 2022 02:50:05 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 19 Dec 2022 02:50:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1671436205; x= 1671522605; bh=/TgQfkHiZPsILU6Pg4Zx4XUedwaIG/fCiEbtj6MluG8=; b=q 9Ry/+b+C9wee79UmRtN4fUJ7If6/uEdEyueaUuAxczU7Cl7F4WrFsmrd7b5DWKV3 O4oNp26Su5JrkksI1/YhAzJ1u+QC7ag796Wg1fwQNaS23IgCAZdikJyD7eDELa9s 8ueBH5UZ5wZ5vEYRoeiPmM4U7el99JwCeDO0FBJohYEV/yfJmIjVaX3R/oRI42uh L2L0a/1O/v5ffWZwc/RQR3Zfeg4VBHbXodrE4dO5rE33/EGAdvKNcK5UoPccdfyr XvzkO6ABmsOgEdTfH45V+z1fOPrpumwwRzna8bLYYltULAkg8+3oOtm29IMqm5ia 6L4bbsgQAs0fT3dCQsQVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1671436205; x= 1671522605; bh=/TgQfkHiZPsILU6Pg4Zx4XUedwaIG/fCiEbtj6MluG8=; b=j 4Rul20eoJ39+IbsepLw93ikm+vraM3KOqUQhPv89ambGyVyrm9r4PEZWeApCklRK RtVM8MnfJznH8V6ER9H76CkcbjG1R0Mm5bm9nezpt1vSWyXpIXSE9safw7eNUXph teaBEu2dQQvdJeuB6/7bjo32loeusMIO7NcB/ocX6EkD1xUbDdsTgwRcEjY/txLk UIVy19AQZNy5cNp93t5xXuFfEaQd99NifWZsIjbGkD7Nf5wD9zzRa32Cq7VfMIwg M3efIHVebcyg+Xeerlv4/W0jRpZO303tH6eU0hrvC8jPYCMy9OasRsHxVvQp73+E OXSS30TISEdC5OqYtrHKQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedvgdduuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttdejnecuhfhrohhmpefirhgv ghcumffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpefgke ffieefieevkeelteejvdetvddtledugfdvhfetjeejieduledtfefffedvieenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhroh grhhdrtghomh X-ME-Proxy: Feedback-ID: i787e41f1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 19 Dec 2022 02:50:04 -0500 (EST) Date: Mon, 19 Dec 2022 08:50:00 +0100 From: Greg KH To: Leesoo Ahn Cc: Oliver Neukum , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usbnet: jump to rx_cleanup case instead of calling skb_queue_tail Message-ID: References: <20221217161851.829497-1-lsahn@ooseel.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Dec 19, 2022 at 04:41:16PM +0900, Leesoo Ahn wrote: > > On 22. 12. 18. 17:55, Greg KH wrote: > > On Sun, Dec 18, 2022 at 01:18:51AM +0900, Leesoo Ahn wrote: > > > The current source pushes skb into dev->done queue by calling > > > skb_queue_tail() and then, call skb_dequeue() to pop for rx_cleanup state > > > to free urb and skb next in usbnet_bh(). > > > It wastes CPU resource with extra instructions. Instead, use return values > > > jumping to rx_cleanup case directly to free them. Therefore calling > > > skb_queue_tail() and skb_dequeue() is not necessary. > > > > > > The follows are just showing difference between calling skb_queue_tail() > > > and using return values jumping to rx_cleanup state directly in usbnet_bh() > > > in Arm64 instructions with perf tool. > > > > > > ----------- calling skb_queue_tail() ----------- > > > │ if (!(dev->driver_info->flags & FLAG_RX_ASSEMBLE)) > > > 7.58 │248: ldr x0, [x20, #16] > > > 2.46 │24c: ldr w0, [x0, #8] > > > 1.64 │250: ↑ tbnz w0, #14, 16c > > > │ dev->net->stats.rx_errors++; > > > 0.57 │254: ldr x1, [x20, #184] > > > 1.64 │258: ldr x0, [x1, #336] > > > 2.65 │25c: add x0, x0, #0x1 > > > │260: str x0, [x1, #336] > > > │ skb_queue_tail(&dev->done, skb); > > > 0.38 │264: mov x1, x19 > > > │268: mov x0, x21 > > > 2.27 │26c: → bl skb_queue_tail > > > 0.57 │270: ↑ b 44 // branch to call skb_dequeue() > > > > > > ----------- jumping to rx_cleanup state ----------- > > > │ if (!(dev->driver_info->flags & FLAG_RX_ASSEMBLE)) > > > 1.69 │25c: ldr x0, [x21, #16] > > > 4.78 │260: ldr w0, [x0, #8] > > > 3.28 │264: ↑ tbnz w0, #14, e4 // jump to 'rx_cleanup' state > > > │ dev->net->stats.rx_errors++; > > > 0.09 │268: ldr x1, [x21, #184] > > > 2.72 │26c: ldr x0, [x1, #336] > > > 3.37 │270: add x0, x0, #0x1 > > > 0.09 │274: str x0, [x1, #336] > > > 0.66 │278: ↑ b e4 // branch to 'rx_cleanup' state > > Interesting, but does this even really matter given the slow speed of > > the USB hardware? > > It doesn't if USB hardware has slow speed but in software view, it's still > worth avoiding calling skb_queue_tail() and skb_dequeue() which work with > spinlock, if possible. But can you actually measure that in either CPU load or in increased transfer speeds? thanks, greg k-h