Received: by 2002:a05:6358:f14:b0:e5:3b68:ec04 with SMTP id b20csp1151652rwj; Sun, 18 Dec 2022 03:11:15 -0800 (PST) X-Google-Smtp-Source: AMrXdXsKlccdE3aA/+uuTU2TaRilO7rO3jRQdB23PayM8ezaumtuiEoZbX9LJHXSUGfXztA+rqyI X-Received: by 2002:a17:907:d40b:b0:7c0:dd55:1dd4 with SMTP id vi11-20020a170907d40b00b007c0dd551dd4mr7005713ejc.42.1671361875382; Sun, 18 Dec 2022 03:11:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671361875; cv=none; d=google.com; s=arc-20160816; b=AXpdsis4eMQzCg+k9DVEhRvhM4UD1fqVIPHLBa4iy2wT55A2OS8NQnA6oYLeGbiNlH 5vkzmSBZBHl8m41hXKVNHPJagoxCiC9R2WlcLA3/MCVjCySEbdNdYFbnQW499/RIC1qr hLRh1gra951lDyK+Szh4lL9p56vK9fOoNZpnoXUiL96yz+X3IkwnaemIWKbiXf6yKYd7 hSaNGto6Uc/GhQdnCUfUwhKP/GCuPY0Zb92TxUWv9JZOBUzvIi1Xrf1BXGmphOl2JQU6 HOvQVm1Yy3DH1j16v8LYSlUSx4dn2WuW/flXauFWvIZU4Swnlpzdu764k0KmlErIFKXK f55Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-signature; bh=Owt8AtGuq4gpGcASBGzAU05B9mtOMW9CXzfxZwQ3ZmI=; b=PpsIFxE4cDUQMhc9Ot+WUziT+aJgBsiidKjZDx4JPhyVXofaeAyNh1ruZWY3WNkJNF XDfj+x+Ix3t2trafVuqjP1Ae+HeiE9Yec2BW+9PSL46zgEwbeOMqS8u+mVyDs5ELHTQV h80qAdK1bFMpt/+KNgAgUNxBZO/CUqDejXkV27O4+Ea6IOgdmyKp1FrTeIILPlqf0kN/ vqzYqHxUEv8kTykQEt3r0GcHWUOfTsY6Jau74g/AWxMP+QvScfMviH2OD0+Wk3msO9zD uR/pT5E3MM1ijIjgziuxeWJdtMt5iSChMGaOc7Wr2E673zoDOoWzmktP42HGmMhx5IUK ViiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@triops.cz header.s=f2019 header.b=WXYMZBq0; dkim=pass header.i=@triops.cz header.s=f2019 header.b=WXYMZBq0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g20-20020a1709065d1400b007ae9bc0b977si7565012ejt.486.2022.12.18.03.10.58; Sun, 18 Dec 2022 03:11:15 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@triops.cz header.s=f2019 header.b=WXYMZBq0; dkim=pass header.i=@triops.cz header.s=f2019 header.b=WXYMZBq0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229693AbiLRKCz (ORCPT + 70 others); Sun, 18 Dec 2022 05:02:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229730AbiLRKCx (ORCPT ); Sun, 18 Dec 2022 05:02:53 -0500 X-Greylist: delayed 60 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sun, 18 Dec 2022 02:02:52 PST Received: from h1.cmg2.smtp.forpsi.com (h1.cmg2.smtp.forpsi.com [81.2.195.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B79855B2 for ; Sun, 18 Dec 2022 02:02:52 -0800 (PST) Received: from lenoch ([91.218.190.200]) by cmgsmtp with ESMTPSA id 6qUNpydpiv5uI6qUPpQpbr; Sun, 18 Dec 2022 11:01:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=triops.cz; s=f2019; t=1671357710; bh=Owt8AtGuq4gpGcASBGzAU05B9mtOMW9CXzfxZwQ3ZmI=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=WXYMZBq0fKIL96pjjhqc8NXZxL4/lsd3wmk1unHapJGxE1er+YMwP3521hWYoiofa sGVXFo8FwmYw2Vqk0QhqGU0lh+St7X5H2dKrmyAVMXOyNj6jdpwWS2p/GCAOyHiSy7 lCI1Mu8nHeJulSvJ1aEcN4e5jh9a9T2KihpkQdYVlCzyAMdOfVaZvK6sY+wNUtsd1F BWwQb66GF2yUDTdsyS/EjXi9uhLxln+KXZqyyTm/nQOSvw9yeYG7eBTm32DsjtpW68 JBlOFV6769243NHjs4oNLWd45WKtECRBesOPn7nc8H6A3cGO1b/Yxvgw6b90nFbWl1 +0kdv62eoqQeQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=triops.cz; s=f2019; t=1671357710; bh=Owt8AtGuq4gpGcASBGzAU05B9mtOMW9CXzfxZwQ3ZmI=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=WXYMZBq0fKIL96pjjhqc8NXZxL4/lsd3wmk1unHapJGxE1er+YMwP3521hWYoiofa sGVXFo8FwmYw2Vqk0QhqGU0lh+St7X5H2dKrmyAVMXOyNj6jdpwWS2p/GCAOyHiSy7 lCI1Mu8nHeJulSvJ1aEcN4e5jh9a9T2KihpkQdYVlCzyAMdOfVaZvK6sY+wNUtsd1F BWwQb66GF2yUDTdsyS/EjXi9uhLxln+KXZqyyTm/nQOSvw9yeYG7eBTm32DsjtpW68 JBlOFV6769243NHjs4oNLWd45WKtECRBesOPn7nc8H6A3cGO1b/Yxvgw6b90nFbWl1 +0kdv62eoqQeQ== Date: Sun, 18 Dec 2022 11:01:45 +0100 From: Ladislav Michl To: Greg KH Cc: Leesoo Ahn , 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: X-CMAE-Envelope: MS4wfA1wtMOBCLHBUmJ8JMmP1mv5RZmEbWCjc8er8LlsDy2p0qnO0Fz6jPLSW3pVe98REsVX2ZAOaLWdFFYlwD9rmJjxar6cJ5OF43SrlCPLyUFOR8+3jJfy /2ahNH46dDGTP2Iza0T1prqs/PUXGDasGEgUT5AoGSqKrlibHluoHEfO6p1j1+pZyIdvWP6DsPTbGutkkP9H12qGNAmaejdh5Fy+vAH+RgSh67G6w7G7AKOb GQilL8215b3I/kjLiySqJxqfcjucDFewDipkSVr7DW9U70zmWbUUIF2Xeqvfh8u/Xp+ujfbAdVHJbhBy71ObOvKlFnQibkKqY77gIGAMMnjU3n1avQoWYZev lL8kPJSVEpjaw8B2kKbX2iwubVsvxlRSCQklD0zFG/vX2/qn+KFd2tFAmP1DaLhuOy0Fmzl7XoyhWWy6OSceobOyf0xEZw== X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 18, 2022 at 09:55:44AM +0100, 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? On the other side, it is pretty nice optimization and a proof someone read the code really carefully. > > Signed-off-by: Leesoo Ahn > > --- > > drivers/net/usb/usbnet.c | 11 ++++++----- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c > > index 64a9a80b2309..924392a37297 100644 > > --- a/drivers/net/usb/usbnet.c > > +++ b/drivers/net/usb/usbnet.c > > @@ -555,7 +555,7 @@ static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags) > > > > /*-------------------------------------------------------------------------*/ > > > > -static inline void rx_process (struct usbnet *dev, struct sk_buff *skb) > > +static inline int rx_process(struct usbnet *dev, struct sk_buff *skb) > > { > > if (dev->driver_info->rx_fixup && > > !dev->driver_info->rx_fixup (dev, skb)) { > > @@ -576,11 +576,11 @@ static inline void rx_process (struct usbnet *dev, struct sk_buff *skb) > > netif_dbg(dev, rx_err, dev->net, "rx length %d\n", skb->len); > > } else { > > usbnet_skb_return(dev, skb); > > - return; > > + return 0; > > } > > > > done: > > - skb_queue_tail(&dev->done, skb); > > + return -1; > > Don't make up error numbers, this makes it look like this failed, not > succeeded. And if this failed, give it a real error value. Note that jumps to 'done' label can be avoided now, so eventual v2 version of that patch doesn't increase total goto entropy. l. > thanks, > > greg k-h