[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH v7 15/16] openvswitch: use new hashtable implementation
- From: Tejun Heo <tj kernel org>
- To: Mathieu Desnoyers <mathieu desnoyers efficios com>
- Cc: snitzer redhat com, fweisbec gmail com, Trond Myklebust netapp com, bfields fieldses org, paul gortmaker windriver com, dm-devel redhat com, agk redhat com, aarcange redhat com, rds-devel oss oracle com, eric dumazet gmail com, venkat x venkatsubra oracle com, ccaulfie redhat com, mingo elte hu, dev openvswitch org, jesse nicira com, josh joshtriplett org, rostedt goodmis org, teigland redhat com, Sasha Levin <levinsasha928 gmail com>, axboe kernel dk, linux-nfs vger kernel org, edumazet google com, linux-mm kvack org, netdev vger kernel org, linux-kernel vger kernel org, ejt redhat com, ebiederm xmission com, lw cn fujitsu com, akpm linux-foundation org, torvalds linux-foundation org, davem davemloft net
- Subject: Re: [dm-devel] [PATCH v7 15/16] openvswitch: use new hashtable implementation
- Date: Mon, 29 Oct 2012 11:22:09 -0700
Hello,
On Mon, Oct 29, 2012 at 02:16:48PM -0400, Mathieu Desnoyers wrote:
> This is just one example in an attempt to show why different hash table
> users may have different constraints: for a hash table entirely
> populated by keys generated internally by the kernel, a random seed
> might not be required, but for cases where values are fed by user-space
> and from the NIC, I would argue that flexibility to implement a
> randomizable hash function beats implementation simplicity any time.
>
> And you could keep the basic use-case simple by providing hints to the
> hash_32()/hash_64()/hash_ulong() helpers in comments.
If all you need is throwing in a salt value to avoid attacks, can't
you just do that from caller side? Scrambling the key before feeding
it into hash_*() should work, no?
Thanks.
--
tejun
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]