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
| ||
|
Date: Mon, 26 Oct 2009 15:55:10 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: Octavian Purdila <opurdila@...acom.com> CC: Krishna Kumar2 <krkumar2@...ibm.com>, Hagen Paul Pfeifer <hagen@...u.net>, netdev@...r.kernel.org Subject: Re: [PATCH next-next-2.6] netdev: better dev_name_hash Octavian Purdila a écrit : > On Monday 26 October 2009 15:07:31 you wrote: >> Eric Dumazet wrote on 10/26/2009 10:58:34 AM: >>> In fact, new10 should be the 'perfect' hash for the "eth%d" >>> netdev use, not jhash (way more expensive in cpu cycles BTW) >>> >>> Most linux machines in the world have less than 10 interfaces, jhash >>> would be really overkill. >>> >>> >>> Thanks >>> >>> >>> [PATCH net-next-2.6] netdev: better dev_name_hash >> Changing Eric's test program to pass a multiplier to string_hash() >> and calling string_hash with multipler=<2 - 63> confirms that 10 >> is almost always the best number for varying netdev names. I print >> the number of times perfect 64 was scored, and for most passed >> device names, the best is for n=10, followed by n=5 and others. >> Almost the worst was n=31, slightly better was n=17. >> >> But other variables matter too, like fewer entries (4K or 1K) but >> above values for are still better compared to n=31. >> > > Hmm, I've found out that it very much depends on the name as well: > > 0 - orig, 1 - jhash, 2 - new10, 3 - new17, 4 - new31 > > $ ./dev_name_hash ixint 16000 0 16 > score 24741 > $ ./dev_name_hash ixint 16000 1 16 > score 17949 > $ ./dev_name_hash ixint 16000 2 16 > score 16000 > $ ./dev_name_hash ixint 16000 3 16 > score 16715 > $ ./dev_name_hash ixint 16000 4 16 > score 18125 > > > $ ./dev_name_hash ixunc 16000 0 16 > score 24741 > $ ./dev_name_hash ixunc 16000 1 16 > score 17904 > $ ./dev_name_hash ixunc 16000 2 16 > score 22180 > $ ./dev_name_hash ixunc 16000 3 16 > score 17065 > $ ./dev_name_hash ixunc 16000 4 16 > score 18038 This is because you chose a 65536 slots hash table, to store 16000 elements The ideal function should be : $ ./dev_name_hash ixunc 16000 5 16 score 16000 unsigned int dev_name_hash_new10bis(const char *name) { unsigned hash = 0; int len = strnlen(name, IFNAMSIZ); int i; for (i = 0; i < len; ++i) hash = 10 * hash + (name[i] - '0'); return hash; } But should we really care ? -- 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
Powered by blists - more mailing lists