Skip to contentSkip to conversation

net: increase receive packet quantum

PATCH In review Stephen Hemminger 2 participants 4 messages Nov 3, 2008 – Nov 4, 2008

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Stephen Hemminger

author
#0 lore raw

PATCH 1/1 net: increase receive packet quantum

This patch gets about 1.25% back on tbench regression.

My change to NAPI for multiqueue support changed the time limit on network receive processing. Under sustained loads like tbench, this can cause the receiver to reschedule prematurely.

Signed-off-by Stephen Hemminger <[email protected]>
net/core/dev.c +4 -7
@@ -2373,7 +2373,7 @@ EXPORT_SYMBOL(__napi_schedule);
 static void net_rx_action(struct softirq_action *h)
 {
 	struct list_head *list = &__get_cpu_var(softnet_data).poll_list;
-	unsigned long start_time = jiffies;
+	unsigned long time_limit = jiffies + 2;
 	int budget = netdev_budget;
 	void *have;
 

@@ -2384,13 +2384,10 @@ static void net_rx_action(struct softirq
 		int work, weight;
 
 		/* If softirq window is exhuasted then punt.
-		 *
-		 * Note that this is a slight policy change from the
-		 * previous NAPI code, which would allow up to 2
-		 * jiffies to pass before breaking out.  The test
-		 * used to be "jiffies - start_time > 1".
+		 * Allow this to run for 2 jiffies since which will allow
+		 * an average latency of 1.5/HZ.
 		 */
-		if (unlikely(budget <= 0 || jiffies != start_time))
+		if (unlikely(budget <= 0 || time_after(jiffies, time_limit)))
 			goto softnet_break;
 
 		local_irq_enable();
maintainer
#1 lore raw

From: Stephen Hemminger <[email protected]>
Date: Mon, 3 Nov 2008 13:03:03 -0800

Quoted 7 lines

This patch gets about 1.25% back on tbench regression.

My change to NAPI for multiqueue support changed the time limit on network receive processing. Under sustained loads like tbench, this can cause the receiver to reschedule prematurely.

Signed-off-by Stephen Hemminger <[email protected]>

I think I'm the guilty party that made that change to your NAPI patches.

I'll apply this to net-next-2.6, thanks Stephen.

author
#2 lore raw
Quoted 9 lines · On Mon, 03 Nov 2008 17:24:28 -0800 (PST) David Miller <[email protected]>…

From: Stephen Hemminger <[email protected]>
Date: Mon, 3 Nov 2008 13:03:03 -0800

Quoted 6 lines

This patch gets about 1.25% back on tbench regression.

My change to NAPI for multiqueue support changed the time limit on network receive processing. Under sustained loads like tbench, this can cause the receiver to reschedule prematurely.

Quoted 6 lines
Quoted 1 line
Signed-off-by Stephen Hemminger <[email protected]>

I think I'm the guilty party that made that change to your NAPI patches.

I'll apply this to net-next-2.6, thanks Stephen.

Maybe you want it as part of the tbench regression recovery in 2.6.28? it seems mostly harmless.

maintainer
#3 lore raw

From: Stephen Hemminger <[email protected]>
Date: Mon, 3 Nov 2008 21:25:21 -0800

Quoted 7 lines
Quoted 1 line · On Mon, 03 Nov 2008 17:24:28 -0800 (PST) David Miller <[email protected]>…

I'll apply this to net-next-2.6, thanks Stephen.

Maybe you want it as part of the tbench regression recovery in 2.6.28? it seems mostly harmless.

Maybe...

I'd rather have it cook in net-next-2.6 for a while.

Taking up more than a jiffie in softirq context is bordering on anti-social and could cause problems especially for RT'ish stuff.

And I'm pretty sure that's why I made the change.