On Mon, Nov 05, 2007 at 02:59:21PM +0200, Radu Rendec wrote: ... > Jamal, I am aware that any computation on the fast path involves some > performance loss. However, I don't see any speed gain with your patch, > because you just moved the ntohl() call inside u32_hash_fold(). Since > u32_hash_fold() is called unconditionally and the only call is that one > in u32_classify(), htohl() will be called exactly the same number of > times.
It seems this performance loss shouldn't be so big because ntohl() is probably quite well optimized in assembler. But, as I've written, since there is max. 1 byte meaningful to us there is some additional possibility to get it other way, but I doubt it's worth to bother, and this can be done with some later patch, after all. > > After almost a week of dealing with this, I still don't think it can be > solved without byte re-ordering. If you guys think my patch is good, I > would be more than glad to send it properly (change the comments as > Jarek suggested and use git). Since I'm quite a newbie with git and > haven't worked with kernel maintainers before, please be patient if it's > not perfect at the first attempt :) What tree/branch should I make the > patch against? If we manage to convince Jamal, IMHO a patch to something current like 2.6.24-rc1-git14 (or maybe -rc2 soon), should suffice (plus some options to diff to get function names etc. eg.: diff -Nurp). Try with Documentation/SubmittingPatches. Git isn't necessary at all. And don't forget about a changelog. Regards, Jarek P. - 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
