On Tue, 2005-13-12 at 10:32 -0800, Jesse Brandeburg wrote:

> To help allay your concerns, someone in our lab is going to test routing 
> between two ports on some older server hardware (<1Ghz Pentium 3 class) 
> today.  I hope to have some results by tomorrow.
> 

that would be great.

> In our benchmark testing we've shown a significant gain across the board 
> from using prefetching across multiple packet sizes.  I have yet to see 
> anyone come up with a test case that shows that using prefetch *hurts* 
> anything.  All we're talking about is how much can we optimize prefetch...
> 
>
> As a compromise, I'd like to go with #1#2#5 as I can show those three have 
> some positive effect, and we've seen both Robert and Jamal report that 
> *any combination* of prefetches is better than none at all.
>
> Doesn't it seem like we're thrashing a dead horse?  :-)  

I dont think there is a single person who has argued _against_
prefetching. David Mosberger's patch on e1000 has been around for at
least 2 years before you published yours and afaik, HP was shipping with
it because it worked well for their hardware and workloads.
You and John keep coming back with the arguement that prefetching is
good therefore we should all use it and be happy with it. But that is 
NOT the problem - so lets settle that first.
The problem, rather, is the dose of prefetch that is provided. To give
you an analogy to medication, you have:
a dose that will make person A feel nothing, kill person X, make person
Y just a little dizzy, but make person Z superman. Dont you think you
are treading on voodoo and not providing medication anymore?

- #125 makes the XEON look good, but NOT the opteron
- #12 makes the opteron look good, but the XEON not at its best.
- copybreak makes the XEON look good but makes it worse for the opteron

The solution is to either pick the minimal dose that doesnt kill X or
make Y dizzy. For person Z, put extra strong medication but that should
be separate. All this of course leads to ifdefs which are considered a
no-no.

> Routing is a good indicator test, but do we want it to be the sole 
> blocking test?  These 
> changes made performance go up, but this discussion clarified that we can 
> do better than what we have.
> 

nothing to do with routing at all - refer to above. 

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to