> > This sounds like something that will always be wrong -- or in other
This is actually just the same tweak you remember me posting before
and I never pushed to get it in mainline, but Jeff's right. The
problem isn't so much in the driver itself, as in how it's used by
I/OAT in the TCP receive code, there are inherent assumptions about
how long a context switch takes compared to how long an offloaded
memcpy takes.
I'm working on using completion interrupts for the device so as not to
end up polling when the CPUs are faster than the code was tuned for,
and doing it in a way that doesn't introduce extra context switches.
I'm hoping to have something ready for 2.6.22, or at least ready for
MM in that time frame.
As for this change in the short term, we did go back and make sure
that it didn't performance worse with the older CPUs supported on
these platforms. We should have tested more intermediate values
instead of just jumping from 1 t o 20 for that threshold.
- Chris
-
