[netfilter-cvslog] r3607 - trunk/patch-o-matic-ng/nf_conntrack/linux-2.6/include/linux/netfilter

[Rusty Russell]

On Sat, 2005-01-22 at 20:05 +0100, yasuyuki at netfilter.org wrote:
> Author: yasuyuki at netfilter.org
> Date: 2005-01-22 20:05:07 +0100 (Sat, 22 Jan 2005)
> New Revision: 3607
> 
> Modified:
>    trunk/patch-o-matic-ng/nf_conntrack/linux-2.6/include/linux/netfilter/nf_conntrack_tuple.h
> Log:
> memcmp() is slow.

No, it's not: the compiler is quite good at optimizing this, and if it's
not, that's a reason to take out the kernel's memcpy routine and shoot
it.

> Modified: trunk/patch-o-matic-ng/nf_conntrack/linux-2.6/include/linux/netfilter/nf_conntrack_tuple.h
> ===================================================================
> --- trunk/patch-o-matic-ng/nf_conntrack/linux-2.6/include/linux/netfilter/nf_conntrack_tuple.h	2005-01-22 13:47:31 UTC (rev 3606)
> +++ trunk/patch-o-matic-ng/nf_conntrack/linux-2.6/include/linux/netfilter/nf_conntrack_tuple.h	2005-01-22 19:05:07 UTC (rev 3607)
> @@ -142,19 +142,25 @@
>  static inline int nf_ct_tuple_src_equal(const struct nf_conntrack_tuple *t1,
>  				        const struct nf_conntrack_tuple *t2)
>  { 
> -	return (!memcmp(t1->src.u3.all, t2->src.u3.all, sizeof(t1->src.u3.all)))
> -	       && (t1->src.u.all == t2->src.u.all)
> -	       && (t1->src.l3num == t2->src.l3num)
> -	       && (t1->dst.protonum == t2->dst.protonum);
> +	return (t1->src.u3.all[0] == t2->src.u3.all[0] &&
> +		t1->src.u3.all[1] == t2->src.u3.all[1] &&
> +		t1->src.u3.all[2] == t2->src.u3.all[2] &&
> +		t1->src.u3.all[3] == t2->src.u3.all[3] &&
> +		t1->src.u.all == t2->src.u.all &&
> +		t1->src.l3num == t2->src.l3num &&
> +		t1->dst.protonum == t2->dst.protonum);
>  }

More importantly, the former code is more readable IMHO.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman