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] [day] [month] [year] [list]
Date:	Tue, 1 Apr 2014 08:33:09 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Eric Dumazet' <eric.dumazet@...il.com>
CC:	Mahesh Bandewar <maheshb@...gle.com>,
	Jay Vosburgh <fubar@...ibm.com>,
	Veaceslav Falico <vfalico@...hat.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	"Eric Dumazet" <edumazet@...gle.com>,
	Maciej Zenczykowski <maze@...gle.com>
Subject: RE: [PATCH 4/5] bonding: Added bond_tlb_xmit() for tlb mode.

From: Eric 
> On Mon, 2014-03-31 at 16:00 +0000, David Laight wrote:
> 
> > Which may or not be faster...
> 
> We don't care of this kind of assertions.
> 
> Bring us real data, or just say nothing. This is a waste of time.
> 
> > As coded the case labels may be dense enough to generate a jump table.
> > If byte reversed the generated code will be a branch tree.
> >
> > A deep branch tree will be worse, a match on the first item of a branch
> > tree will almost certainly be better.
> > I'm not going to guess where the breakeven point is for any modern cpus.
> 
> This is ridiculous, there is no jumptable for ETH_P_IP, ETH_P_IPX,
> ETH_P_IPV6.
> 
> Its not like their value will ever be 1 , 2 and 3
> 
> I suggest you take a look at the existing code in whole networking
> stack. This is how we coded things, because there is no need to do
> ntohs(variable) when we can simply write htons(constant) which even a
> dumb compiler can understand. (We used to have __constant_htons() but it
> looks its not needed these days.)

I am fully aware of the general advantage of doing htons(constant)
in a comparison, rather than converting the variable.

I am also aware of the different ways the compiler can compile
a switch statement, and many of the problems with each.

I'll admit to not looking at the values of those constants, so
may have assumed they were small integers (I was probably thinking
they were the values that appear in sockaddr).

However I stand by my assertion that given a switch statement that
is likely to have dense case labels you probably don't want to
byteswap the value so that the compiler generates a branch tree.
The 'problem' is that the jump table is likely to be a data cache
miss, but the branch tree might predict the correct outcome - so
the branch tree might be faster for some values of the expression.

	David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ