On Llu, 2005-01-10 at 02:41, Paul Gortmaker wrote:
Using rdtscl over the area affected by the patch on the two variants for a
sample of 234 small packets, I see an average of 4141 for using the
existing stack scratch area, and 4162 for using skb_padto. That is a
difference of about 0.5%, which is significantly less than the typical
spread in the samples themselves. To help give a relevant scale, feeding
it a larger 1400 byte packet comes in at around 60,000 cycles on this
particular box. Am I being optimistic to see this as good news -- meaning
that there is no longer a need for driver specific padto implementations,
whereas it looks like there was back when you did your tests?
It means that padto has improved a lot (or the underlying allocators).
It also still means the patch makes the code slower and introduces
changes that have no benefit into the kernel, so while its good to see
its not relevant its still a pointless change.