From: Eric Dumazet <eric.dumazet@gmail.com>
To: Octavian Purdila <opurdila@ixiacom.com>
Cc: Krishna Kumar2 <krkumar2@in.ibm.com>,
Hagen Paul Pfeifer <hagen@jauu.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH next-next-2.6] netdev: better dev_name_hash
Date: Mon, 26 Oct 2009 15:55:10 +0100 [thread overview]
Message-ID: <4AE5B84E.8040505@gmail.com> (raw)
In-Reply-To: <200910261631.44666.opurdila@ixiacom.com>
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 ?
next prev parent reply other threads:[~2009-10-26 14:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-25 19:58 [PATCH next-next-2.6] netdev: better dev_name_hash Octavian Purdila
2009-10-25 20:17 ` Hagen Paul Pfeifer
2009-10-25 21:24 ` Eric Dumazet
2009-10-25 21:55 ` Octavian Purdila
2009-10-25 22:41 ` Hagen Paul Pfeifer
2009-10-25 22:45 ` Octavian Purdila
2009-10-26 5:28 ` Eric Dumazet
2009-10-26 13:07 ` Krishna Kumar2
2009-10-26 14:31 ` Octavian Purdila
2009-10-26 14:55 ` Eric Dumazet [this message]
2009-10-26 15:52 ` Octavian Purdila
2009-10-26 16:55 ` Stephen Hemminger
2009-10-26 17:45 ` Stephen Hemminger
2009-10-27 1:24 ` David Miller
2009-10-27 1:40 ` Eric Dumazet
2009-10-26 6:30 ` Stephen Hemminger
2009-10-26 7:48 ` Eric Dumazet
2009-10-26 4:43 ` Stephen Hemminger
2009-10-26 22:36 ` [PATCH] dcache: better name hash function Stephen Hemminger <shemminger@vyatta.com>, Al Viro
2009-10-27 2:45 ` Eric Dumazet
2009-10-27 3:53 ` Stephen Hemminger
2009-10-27 16:38 ` Rick Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE5B84E.8040505@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=hagen@jauu.net \
--cc=krkumar2@in.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).