linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ladislav Michl <oss-lists@triops.cz>
To: Greg KH <greg@kroah.com>
Cc: Leesoo Ahn <lsahn@ooseel.net>, 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 11:01:45 +0100	[thread overview]
Message-ID: <Y57lCffa61raoiDO@lenoch> (raw)
In-Reply-To: <Y57VkLKetDsbUUjC@kroah.com>

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 <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.

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

  reply	other threads:[~2022-12-18 10:01 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
2022-12-18 10:01   ` Ladislav Michl [this message]
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=Y57lCffa61raoiDO@lenoch \
    --to=oss-lists@triops.cz \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=greg@kroah.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).