| To: | Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, "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:37:16 -0700 |
| Cc: | akpm@xxxxxxxxxx, hadi@xxxxxxxxxx, tcw@xxxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, niv@xxxxxxxxxx |
| In-reply-to: | <15736.38178.445310.714015@xxxxxxxxxxxx> |
| References: | <15736.38178.445310.714015@xxxxxxxxxxxx> |
| Reply-to: | "Martin J. Bligh" <Martin.Bligh@xxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
> And NAPI scheme behaves different since we can not assume that all network > traffic is well-behaved like TCP. System has to be manageable and to "perform" > under any network load not only for well-behaved TCP. So of course we will > see some differences -- there are no free lunch. Simply we can not blindly > look at one test. IMO NAPI is the best overall performer. The number speaks > for themselves. I don't doubt it's a win for most cases, we just want to reap the benefit for the large SMP systems as well ... the fundamental mechanism seems very scalable to me, we probably just need to do a little tuning? > NAPI kernel path is included in 2.4.20-pre4 the comparison below is mainly > between e1000 driver w and w/o NAPI and the NAPI port to e1000 is still > evolving. We are running from 2.5.latest ... any updates needed for NAPI for the driver in the current 2.5 tree, or is that OK? Thanks, Martin. |
| Previous by Date: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Martin J. Bligh |
|---|---|
| Next by Date: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Dave Hansen |
| Previous by Thread: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Robert Olsson |
| Next by Thread: | Re: Early SPECWeb99 results on 2.5.33 with TSO on e1000, Robert Olsson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |