linux-kernel - Re: Poor UDP performance using 2.6.21-rc5-rt5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Apr 2007 21:04:45 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"dave_sperry@...e.org" <dasperry@...cast.net>
Cc:	Dave Sperry <dave_sperry@...e.org>, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Poor UDP performance using 2.6.21-rc5-rt5


* dave_sperry@...e.org <dasperry@...cast.net> wrote:

> The Intel NIC seems to behave better under RT

yeah.

> I think there is some kind of bad behavior happening in the Nvidia 
> driver with respect to softirq-net-tx and IRQ-8406.

yes. Part of the problem is that the forcedeth.c driver does not fully 
support NAPI - today i've implemented those bits (see them below), based 
on your testcase. The other part is that the Intel NIC uses MSI, while 
foredeth uses fasteoi, correct? [you can see this in /proc/interrupts]

there are a few other things i'm working on to improve this. I've 
uploaded -rt9 which is the current state of affairs. Note that using 
-rt9 you'll likely only see IRQ-8406 overhead in the system, because 
i've added an optimization to do process the softirq-net-tx workload in 
the hardirq thread if the priority of the two is the same (which is the 
default behavior). But -rt9 is still work in progress that is not fully 
finished yet: in some cases i'm seeing 'fluctuating performance' 
problems on forcedeth that werent there before.

	Ingo

--------------------->
From: Ingo Molnar <mingo@...e.hu>
Subject: [patch] forcedeth.c: improve NAPI handler

another forcedeth.c thing: i noticed that its NAPI handler does not do 
tx-ring processing. The patch below implements this - tested on 
DESC_VER_2 hardware, with CONFIG_FORCEDETH_NAPI=y.

Signed-off-by: Ingo Molnar <mingo@...e.hu>

Index: linux/drivers/net/forcedeth.c
===================================================================
--- linux.orig/drivers/net/forcedeth.c
+++ linux/drivers/net/forcedeth.c
@@ -3118,9 +3118,17 @@ static int nv_napi_poll(struct net_devic
 	int retcode;
 
 	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+		spin_lock_irqsave(&np->lock, flags);
+		nv_tx_done(dev);
+		spin_unlock_irqrestore(&np->lock, flags);
+
 		pkts = nv_rx_process(dev, limit);
 		retcode = nv_alloc_rx(dev);
 	} else {
+		spin_lock_irqsave(&np->lock, flags);
+		nv_tx_done_optimized(dev, np->tx_ring_size);
+		spin_unlock_irqrestore(&np->lock, flags);
+
 		pkts = nv_rx_process_optimized(dev, limit);
 		retcode = nv_alloc_rx_optimized(dev);
 	}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/