On Tuesday 2009-03-24 22:39, Eric Dumazet wrote: >>> memcmp() can't make any assumptions about alignment. >>> Whereas we _know_ this thing is exactly 16-bit aligned. >>> >>> All of the optimized memcmp() implementations look for >>> 32-bit alignment and punt to byte at a time comparison >>> loops if things are not aligned enough. >> >> Yes, I seem to remember glibc doing something like >> [...] >> Is the cost of testing for non-4-divisibility expensive enough >> to warrant not usnig memcmp? >> >> Irrespective of all that, I think putting the interface comparison >> code should be agglomerated in a function/header so that it is >> replicated across iptables, ip6tables, ebtables, arptables, etc. > >memcmp() is fine, but how is it solving the masking problem we have ? You are right; we would have to calculate the prefix length of the mask first. (And I think we can assume that there will not be any 1s in the mask after the first 0.) It would consume CPU indeed. >Also in the case of arp_tables, _a is long word aligned, while _b and _mask >are not. > >If you look various ifname_compare(), we have two different implementations. > >So yes, a factorization is possible for three ip_tables.c, ip6_tables.c and > xt_physdev.c. Very well. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
