From: Wang Jian <lark@linux.net.cn>
To: hadi@cyberus.ca
Cc: Thomas Graf <tgraf@suug.ch>, netdev <netdev@oss.sgi.com>
Subject: Re: [PATCH] improvement on net/sched/cls_fw.c's hash function
Date: Tue, 05 Apr 2005 22:18:53 +0800 [thread overview]
Message-ID: <20050405213023.0256.LARK@linux.net.cn> (raw)
In-Reply-To: <1112705689.1088.209.camel@jzny.localdomain>
Hi jamal,
On 05 Apr 2005 08:54:49 -0400, jamal <hadi@cyberus.ca> wrote:
>
> Why dont you run a quick test? Very easy to do in user space.
> Enter two sets of values using the two different approaches; yours and
> the current way tc uses nfmark (incremental). And then apply the jenkins
> approach you had to see how well it looks like? I thinkw e know how it
> will look with current hash - but if you can show its not so bad in the
> case of jenkins as well it may be an acceptable approach,
>
I am not saying that we must use jenkins. We may use a less expensive
hash function than jenkins, but better than & 0xFF.
Anyway, I have done userspace test for jhash. The following test is done
in a AMD Athlon 800MHz without other CPU load.
-- snip jhash_test.c --
typedef unsigned long u32;
typedef unsigned char u8;
#include <linux/jhash.h>
#include <stdlib.h>
int main(void)
{
u32 i;
u32 h;
for (i = 0; i < 10000000; i++) {
h = jhash_1word(i, 0xF30A7129) & 0xFFL;
// printf("h is %u\n", h);
}
return 0;
}
-- snip --
[root@qos ~]# gcc jhash_test.c
[root@qos ~]# time ./a.out
0.77user 0.00system 0:00.77elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+81minor)pagefaults 0swaps
--snip simple_hash.c --
typedef unsigned long u32;
typedef unsigned char u8;
#include <stdlib.h>
int main(void)
{
u32 i;
u32 h;
for (i = 0; i < 10000000; i++) {
h = i & 0xFF;
// printf("h is %u\n", h);
}
return 0;
}
-- snip --
[root@qos ~]# gcc simple_hash.c
[root@qos ~]# time ./a.out
0.02user 0.00system 0:00.02elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+81minor)pagefaults 0swaps
The simple method is far better in performance. For extreme situation,
100Mbps ethernet has about 148800 pps for TCP. Replace 10000000 with
150000.
[root@qos ~]# time ./a.out
0.01user 0.00system 0:00.01elapsed 83%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+81minor)pagefaults 0swaps
So use jhash is not big deal at 100Mbps.
For 1000Mbps ethernet, replace 10000000 with 1489000.
[root@qos ~]# time ./a.out
0.11user 0.00system 0:00.11elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+81minor)pagefaults 0swaps
It's expected that a more hot CPU is used for GE, for example, 2.4GHz
CPU. So
0.11 / (2.4/0.8) = 0.04.
This is still not a big problem for a dedicated linux box for qos
control. We know that 500Mbps is already a bottleneck here.
--
lark
next prev parent reply other threads:[~2005-04-05 14:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 5:35 [PATCH] improvement on net/sched/cls_fw.c's hash function Wang Jian
2005-04-05 5:37 ` David S. Miller
2005-04-05 6:05 ` Wang Jian
2005-04-05 10:25 ` jamal
2005-04-05 10:38 ` Thomas Graf
2005-04-05 11:25 ` Wang Jian
2005-04-05 12:16 ` Thomas Graf
2005-04-05 12:39 ` Wang Jian
2005-04-05 12:52 ` Thomas Graf
2005-04-05 13:29 ` Wang Jian
2005-04-05 12:54 ` jamal
2005-04-05 14:18 ` Wang Jian [this message]
2005-04-05 16:11 ` jamal
2005-04-06 6:45 ` Wang Jian
2005-04-06 12:16 ` jamal
2005-04-06 12:30 ` Thomas Graf
2005-04-06 13:01 ` Wang Jian
2005-04-06 13:34 ` jamal
2005-04-06 13:45 ` Thomas Graf
2005-04-06 14:10 ` Thomas Graf
2005-04-06 18:15 ` David S. Miller
2005-04-06 18:31 ` Thomas Graf
2005-04-07 0:55 ` [RFC] dynamic hash table size & xor hash function for cls_fw Thomas Graf
2005-04-07 10:38 ` jamal
2005-04-07 10:47 ` Wang Jian
2005-04-07 10:51 ` Thomas Graf
2005-04-07 11:07 ` jamal
2005-04-07 13:09 ` [PATCH] [PKT_SCHED]: improve hashing performance of cls_fw Thomas Graf
2005-04-07 13:31 ` Wang Jian
2005-04-07 13:52 ` Thomas Graf
2005-04-07 14:03 ` Wang Jian
2005-04-06 13:36 ` [PATCH] improvement on net/sched/cls_fw.c's hash function Eran Mann
2005-04-06 13:53 ` Wang Jian
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=20050405213023.0256.LARK@linux.net.cn \
--to=lark@linux.net.cn \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.com \
--cc=tgraf@suug.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.