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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.