lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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