[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1341969736.13724.32.camel@joe2Laptop>
Date: Tue, 10 Jul 2012 18:22:16 -0700
From: Joe Perches <joe@...ches.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH 03/16] tcp: Maintain dynamic metrics in local cache.
On Tue, 2012-07-10 at 18:01 -0700, David Miller wrote:
> From: Joe Perches <joe@...ches.com>
> Date: Tue, 10 Jul 2012 17:44:46 -0700
>
> > I'd guess the one above is faster to execute.
>
> It is.
>
> > If it's not, the code in ipv6_addr_equal
> > should be reverted. commit fed85383ac34d82
> > ("[IPV6]: Use XOR and OR rather than mutiple ands for ipv6 address comparisons")
>
> Not necessarily.
>
> My version here is faster because we unconditionally test
> the first word, which we need to do for both the ipv4 and
> ipv6 cases.
I don't think that's correct.
Look at what I posted again.
If it's IPv4,
if (a->family == AF_INET)
return a->addr.a4 == b->addr.a4;
return ipv6_addr_equal((const struct in6_addr *)&a->addr.a6,
(const struct in6_addr *)&b->addr.a6);
so it's a single word test or a 4 word test.
Your code is compare/branch/continue in a loop with an
increment and test. I find it hard to believe that's
faster. I suppose it _could_ be faster dependent on the
data in the words though.
> The ipv6 routine optimization you mention exists in a
> world where we know we have an ipv6 address always, which
> is not the case here.
What do I miss?
Is there a case where a->family is neither
AF_INET or AF_INET6?
> If anything, we should do XOR's on the final three words,
> but we should not remove the first word optimization for
> ipv4 which is the common case.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists