linux-kernel - Re: eth_type_trans(): Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49227E37.6070100@cosmosbay.com>
Date:	Tue, 18 Nov 2008 09:35:03 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Ingo Molnar <mingo@...e.hu>, David Miller <davem@...emloft.net>,
	rjw@...k.pl, linux-kernel@...r.kernel.org,
	kernel-testers@...r.kernel.org, cl@...ux-foundation.org,
	efault@....de, a.p.zijlstra@...llo.nl,
	Stephen Hemminger <shemminger@...tta.com>
Subject: Re: eth_type_trans(): Re: [Bug #11308] tbench regression on each
 kernel release from 2.6.22 -&gt; 2.6.28

Linus Torvalds a écrit :
> 
> On Tue, 18 Nov 2008, Eric Dumazet wrote:
>>> *
>>> * Compare two ethernet addresses, returns 0 if equal
>>> */
>>> static inline unsigned compare_ether_addr(const u8 *addr1, const u8 *addr2)
>>> {
>>>        const u16 *a = (const u16 *) addr1;
>>>        const u16 *b = (const u16 *) addr2;
>>>
>>>        BUILD_BUG_ON(ETH_ALEN != 6);
>>>        return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
> 
> Btw, at least on some Intel CPU's, it would be faster to do this as a 
> 32-bit xor and a 16-bit xor. And if we can know that there is always 2 
> bytes at the end (because of how the thing was allocated), it's faster 
> still to do it as a 64-bit xor and a mask.
> 
> And that's true even if the addresses are only 2-byte aligned.
> 

Yes, this is allowed, we always have at least 8 bytes for both arrays,
when called from eth_type_trans() at least.

I tried this idea and got nice assembly on 32 bits:

 158:   33 82 38 01 00 00       xor    0x138(%edx),%eax
 15e:   33 8a 34 01 00 00       xor    0x134(%edx),%ecx
 164:   c1 e0 10                shl    $0x10,%eax
 167:   09 c1                   or     %eax,%ecx
 169:   74 0b                   je     176 <eth_type_trans+0x87>

And very nice assembly on 64 bits of course (one xor, one shl)

About alignments, we have aligned addr2, but not addr1

Nice oprofile improvement in eth_type_trans(), 0.17 % instead of 0.41 %

opreport -l vmlinux | grep eth_type_trans
38797     0.1710  eth_type_trans



[PATCH] eth: Declare an optimized compare_ether_addr_64bits() function

Linus mentioned we could try to perform long word operations, even
on potentially unaligned addresses, on x86 at least.

This patch implements a compare_ether_addr_64bits() function,
that handles the case of x86 cpus, but might be used on other arches as well.

Signed-off-by: Eric Dumazet <dada1@...mosbay.com>
---

View attachment "compare_ether_addr_64bits.patch" of type "text/plain" (2439 bytes)