netdev - Re: [PATCH] eth: Declare an optimized compare_ether_addr

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]

Date:	Sat, 22 Nov 2008 08:30:30 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	"David S. Miller" <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH] eth: Declare an optimized compare_ether_addr_64bits()
 function

Stephen Hemminger a écrit :
> On Sat, 22 Nov 2008 08:19:17 +0100
> Eric Dumazet <dada1@...mosbay.com> wrote:
> 
>> Hello David, this is a resend of a patch previously sent in a 
>> "tbench regression ..." thread on lkml
>>
>> We should also address the problem of skb_pull(skb, ETH_HLEN);
>> in eth_type_trans() :
>>
>> Being not inlined, this force eth_type_trans() to be a non
>> leaf function, that cost precious cpu cycles on many arches.
>>
>> Thank you
>>
>> [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.
>>
>> 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)
>>
>> Nice oprofile improvement in eth_type_trans(), 0.17 % instead of 0.41 %,
>> expected since we remove 8 instructions on a fast path.
>>
>> 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,
>> if their potential misaligned long word reads are not expensive.
>>
> 
> Why invent another function? Why not just have compare_ether_addr() be
> as optimized as possible, could even set it up to be overloadable by
> asm code.

Because I am not sure we can fetch 8 bytes from addr1 & addr2 from all
call sites. Better be safe, and convert each call sites after an audit.
Then, when fully audited, rename the function ?


--
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