On Tuesday 13 March 2007 15:01, Andi Kleen wrote: > David Miller <[EMAIL PROTECTED]> writes: > > From: Rick Jones <[EMAIL PROTECTED]> > > Date: Mon, 12 Mar 2007 17:05:39 -0700 > > > > > Being paranoid - are there no worries about the alignment of dest? > > > > If it's an issue, it's an issue elsewhere too, as the places > > where Stephen took this idiomatic code from is the code > > ethernet handling and that runs on every input packet via > > eth_type_trans(). > > As a quick note -- when you tell gcc the expected alignment > by using correct types then moderm gcc should generate fast inline code > for memcpy/memcmp/etc. by itself. It only falls back to a slow generic > function when it cannot figure out the alignment or the size. > > So I expect just using u32 * instead of char * should have the same > effect and would be somewhat cleaner and the memcmp could be kept.
For memcpy() yes you can have some optimizations. But memcmp() has a strong semantic (in libc). memcmp(a, b, 6) should do 6 byte compares and conditional branches, regardless of a/b alignment. Or use the x86 "rep cmpsb" instruction that basically has the same cost. The trick we use in compare_ether_addr() reduces to one some arithmetic and one test. return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0; I found this line as clean as memcmp(a, b, 6) (On x86_64, were alignment is not mandatory, we could do : ((*(long *)a ^ *(long*)b) << 16) != 0) (only if we can always read two extra bytes without faulting, of course :) ) - 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
