All of lore.kernel.org
 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 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.