On Tue, 13 Dec 2005, jamal wrote:
On Mon, 2005-12-12 at 20:38 +0100, Robert Olsson wrote:
> jamal writes:

>  > Robert, what about just #1? Maybe thats the best compromise that would
>  > work for all.
>
> I've tried that before with flow test and got contribution from #2
> > 0 prefetch 756 kpps
> 1 prefetch 805 kpps (first)
> 2 prefetch 821 kpps (first two)
> 5 prefetch 803 kpps (all)
>
>
>  > Also, I am really hoping that someone will test with older hardware
>  > where i claim to have seen prefetch causing problems.
>
> We give this up for now unless you or somebody else has some very good idea
> how handle prefetching in generic way.
>
> I'll use #12 and you'll use #125 Intel uses #12345 etc
>
> Or do we all benefit from #12?
>

I am willing to say lets go with #12, but now more than ever i am more
concerned about the older hardware.

I think if we cant test older hardware this patch should not go in at
all. Or should go in with only ifdefs.

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.

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? :-) 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.

Jesse
-
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