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 17:52:51 +0200 From: Octavian Purdila <opurdila@...acom.com> To: Eric Dumazet <eric.dumazet@...il.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 On Monday 26 October 2009 16:55:10 you wrote: > > 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; > } > Eric, thanks a lot for your help. This is turning into a very instructive thread for me :) 10bis performs better for ixunc but interestingly performs worse for ixint now. I also get mixed results for the two when using other names like ppp or gtp. 2 - new10, 3 - new10bis score 49852 $ ./dev_name_hash ixint 32000 3 14 score 53194 $ ./dev_name_hash ixunc 32000 2 14 score 55232 $ ./dev_name_hash ixunc 32000 3 14 score 48168 > But should we really care ? I'm just testing various common cases we use here ({ixint,ixunc,gtp,ppp,gre} {1000,16000,32000,128000} {14,16}). Ideally we want a hash function that performs better in all cases - but I understand that it may not be possible. I will play more with it and see if I can come up with something better, but in any case the new{10,10bis,17,31} performs much better than full_name_hash and most of the time better that jhash . -- 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