netdev - RE: [PATCH net-next v2 2/2] net: ovs: use CRC32 accelerated flow hash if available

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: <AE90C24D6B3A694183C094C60CF0A2F6026B7487@saturn3.aculab.com>
Date:	Fri, 13 Dec 2013 10:01:20 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Jesse Gross" <jesse@...ira.com>,
	"Francesco Fusco" <ffusco@...hat.com>
Cc:	"netdev" <netdev@...r.kernel.org>, <dev@...nvswitch.org>,
	"Daniel Borkmann" <dborkman@...hat.com>,
	"Thomas Graf" <tgraf@...hat.com>
Subject: RE: [PATCH net-next v2 2/2] net: ovs: use CRC32 accelerated flow hash if available

> From: Jesse Gross
...
> Out of curiosity, did you try using crc32q? OVS data structures are
> already aligned to 8 bytes. It would also be interesting to know if a
> parallelized implementation is worthwhile, although my guess is that
> the OVS flow key is not quite long enough.

My thoughts exactly.
Given this is a hash it could crc alternate words into separate
accumulators and the combine the values at the end.
That way you are still doing sequential accesses to the data.
(The crc instruction might be better than an xor for the combine.)
If the cpu has 3 execution units that can do crc, use them all.

It might be that the hash function is now an insignificant cost.
Looking at how much hashing the data twice (discarding the first
result - assign to global volatile data) slows things down can
help determine this.

	David