netdev - Re: [PATCH net-next] 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: <CAEP_g=-tKCnO=xWSHPj7aA7=E8ZxDAx=1OTfwqEqF3AAuKQenQ@mail.gmail.com>
Date:	Tue, 10 Dec 2013 13:36:22 -0800
From:	Jesse Gross <jesse@...ira.com>
To:	Thomas Graf <tgraf@...hat.com>
Cc:	David Miller <davem@...emloft.net>, ffusco@...hat.com,
	netdev <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	Daniel Borkmann <dborkman@...hat.com>
Subject: Re: [PATCH net-next] net: ovs: use CRC32 accelerated flow hash if available

On Tue, Dec 10, 2013 at 12:47 PM, Thomas Graf <tgraf@...hat.com> wrote:
> On 12/10/2013 08:36 PM, David Miller wrote:
>>
>> From: Jesse Gross <jesse@...ira.com>
>> Date: Tue, 10 Dec 2013 11:28:08 -0800
>>
>>> I think this is definitely a good optimization to do given that so
>>> much of the work that OVS does is hashing. However, isn't there a
>>> library where there would be a more appropriate place to put this?
>>
>>
>> I also honestly don't see why we want to special case OVS at all
>> here.  This faster hashing would be useful for socket demux and
>> other locations in the kernel.
>>
>> When I see changes like this my only reaction is "sad face".
>
>
> We discussed this heavily and decided to go with the minimal approach
> first to collect some feedback. We were not sure whether the runtime
> check, function pointer and hardware dependencies are something other
> subsystems that are less x86_64 centric would want to live with.
>
> That said, we are _very_ willing to do the work and move it to lib/
> to make it available to other consumers but one should be aware that
> crc32 based hashes are not as generally usable as jhash.

Most hash users probably don't care what the actual hash function is,
as long as it is consistent. Couldn't you have a function that uses
CRC32 if it is available (or whatever is appropriate on a given
architecture) and jhash otherwise? Most users would then be able to
call this function without knowing or caring about the various quirks.

We could also potentially use the static key stuff to get the right
hash function as well.
--
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