From: Greg KH <greg@kroah.com>
To: Leesoo Ahn <lsahn@ooseel.net>
Cc: Oliver Neukum <oneukum@suse.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
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
Date: Sun, 18 Dec 2022 09:55:44 +0100 [thread overview]
Message-ID: <Y57VkLKetDsbUUjC@kroah.com> (raw)
In-Reply-To: <20221217161851.829497-1-lsahn@ooseel.net>
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?
> Signed-off-by: Leesoo Ahn <lsahn@ooseel.net>
> ---
> 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.
thanks,
greg k-h
next prev parent reply other threads:[~2022-12-18 8:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-17 16:18 [PATCH] usbnet: jump to rx_cleanup case instead of calling skb_queue_tail Leesoo Ahn
2022-12-18 8:55 ` Greg KH [this message]
2022-12-18 10:01 ` Ladislav Michl
2022-12-19 7:41 ` Leesoo Ahn
2022-12-19 7:50 ` Greg KH
2022-12-19 8:09 ` Leesoo Ahn
2022-12-19 8:55 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y57VkLKetDsbUUjC@kroah.com \
--to=greg@kroah.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=lsahn@ooseel.net \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).