All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Hayes Wang <hayeswang@realtek.com>
Cc: Oliver Neukum <oneukum@suse.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: NAPI on USB network drivers
Date: Wed, 25 Jan 2017 06:13:11 -0800	[thread overview]
Message-ID: <1485353591.5145.8.camel@edumazet-glaptop3.roam.corp.google.com> (raw)
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB201A134A7@RTITMBSV06.realtek.com.tw>

On Wed, 2017-01-25 at 09:39 +0000, Hayes Wang wrote:
> Oliver Neukum [mailto:oneukum@suse.com]
> > Sent: Wednesday, January 25, 2017 5:35 PM
> [...]
> > looking at r8152 I noticed that it uses NAPI. I never considered
> > this for the generic USB networking code as you cannot disable
> > interrupts for USB. Is it still worth it? What are the benefits?
> 
> You could use napi_gro_receive() and it influences the performance.

You also could use napi_complete_done() instead of napi_complete(), as
it allows users to tune the performance vs latency for GRO.

Looking at this driver, I do not see any limitation on the number of
skbs that can be pushed into tp->rx_queue.

I wonder if this queue can end up consuming all memory of a host under
stress.

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e1466b4d2b6c727148a884672bbd9593bf04b3ac..221df4a931b5c1073f1922d0fa0bbff158c73b7d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1840,7 +1840,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
 				stats->rx_packets++;
 				stats->rx_bytes += pkt_len;
 			} else {
-				__skb_queue_tail(&tp->rx_queue, skb);
+				if (unlikely(skb_queue_len(&tp->rx_queue) >= 1000))
+					kfree_skb(skb);
+				else
+					__skb_queue_tail(&tp->rx_queue, skb);
 			}
 
 find_next_rx:

  parent reply	other threads:[~2017-01-25 14:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25  9:34 NAPI on USB network drivers Oliver Neukum
     [not found] ` <1485336881.16604.2.camel-IBi9RG/b67k@public.gmane.org>
2017-01-25  9:39   ` Hayes Wang
     [not found]     ` <0835B3720019904CB8F7AA43166CEEB201A134A7-JIZ+AM9kKNzKeZCINmmWEypo8c9IxeqyAjHCUHv49ws@public.gmane.org>
2017-01-25 13:33       ` Oliver Hartkopp
2017-01-25 20:57         ` Alexander Duyck
2017-01-26 18:59           ` Oliver Hartkopp
2017-01-25 14:13     ` Eric Dumazet [this message]
     [not found]       ` <1485353591.5145.8.camel-XN9IlZ5yJG9HTL0Zs8A6p+yfmBU6pStAUsxypvmhUTTZJqsBc5GL+g@public.gmane.org>
2017-01-26  1:43         ` Hayes Wang
2017-01-25 19:32 ` David Miller

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=1485353591.5145.8.camel@edumazet-glaptop3.roam.corp.google.com \
    --to=eric.dumazet@gmail.com \
    --cc=hayeswang@realtek.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.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.