netdev - RE: [PATCH 4/5] bonding: Added bond_tlb

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]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6ED8F6@AcuExch.aculab.com>
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