netdev
[Top] [All Lists]

Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000
From: "Martin J. Bligh" <Martin.Bligh@xxxxxxxxxx>
Date: Fri, 06 Sep 2002 07:29:21 -0700
Cc: hadi@xxxxxxxxxx, tcw@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, niv@xxxxxxxxxx
In-reply-to: <20020905.235159.128049953.davem@redhat.com>
References: <20020905.235159.128049953.davem@redhat.com>
Reply-to: "Martin J. Bligh" <Martin.Bligh@xxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
> Stupid question, are you sure you have CONFIG_E1000_NAPI enabled?
> 
> NAPI is also not the panacea to all problems in the world.

No, but I didn't expect throughput to drop by 40% or so either,
which is (very roughly) what happened. Interrupts are a pain to
manage and do affinity with, so NAPI should (at least in theory)
be better for this kind of setup ... I think.
 
> I bet your greatest gain would be obtained from going to Tux
> and using appropriate IRQ affinity settings and making sure
> Tux threads bind to same cpu as device where they accept
> connections.
> 
> It is standard method to obtain peak specweb performance.

Ah, but that's not really our goal - what we're trying to do is
use specweb as a tool to simulate a semi-realistic customer
workload, and improve the Linux kernel performance, using that
as our yardstick for measuring ourselves. For that I like the
setup we have reasonably well, even though it won't get us the
best numbers.

To get the best benchmark numbers, you're absolutely right though.

M.


<Prev in Thread] Current Thread [Next in Thread>