From: "David S. Miller" <davem@redhat.com>
To: hadi@cyberus.ca
Cc: nf@hipac.org, linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [RFC] High Performance Packet Classifiction for tc framework
Date: Thu, 7 Aug 2003 13:05:02 -0700 [thread overview]
Message-ID: <20030807130502.4af9c815.davem@redhat.com> (raw)
In-Reply-To: <1060286331.1025.73.camel@jzny.localdomain>
On 07 Aug 2003 15:58:51 -0400
jamal <hadi@cyberus.ca> wrote:
> > Yes, it does. Still the question is how to solve this
> > generally. Consider the following example ruleset:
> >
> > 1) src ip 10.0.0.0/30 dst ip 20.0.0.0/20
> > 2) src ip 10.0.0.0/28 dst ip 20.0.0.0/22
> > 3) src ip 10.0.0.0/26 dst ip 20.0.0.0/24
> > 4) src ip 10.0.0.0/24 dst ip 20.0.0.0/26
> > 5) src ip 10.0.0.0/22 dst ip 20.0.0.0/28
> > 6) src ip 10.0.0.0/20 dst ip 20.0.0.0/30
> >
> > So you have 1 src ip hash and #buckets(src ip hash) many
> > dst ip hashes. In order to achieve maximum performance
> > you have to minimize the number of collisions in the
> > hash buckets. How would you choose the hash function
> > and what would the construction look like?
> >
>
> It can be done by using the masks - but it would look really ugly. I
> suppose just providing a good user interface is valuable.
If you input all the keys into the Jenkins hash, how does
it perform? Has anyone even tried that and compared it
to all of these fancy multi-level tree like hash things?
I think Jenkins would work very well for exactly this kind
of application. And it's fully available to the entire kernel
via linux/jhash.h and already in use by other things such
as the routing cache and the netfilter conntrack code.
next prev parent reply other threads:[~2003-08-07 20:05 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-14 8:45 [RFC] High Performance Packet Classifiction for tc framework Michael Bellion and Thomas Heinz
2003-07-16 5:02 ` jamal
2003-07-17 13:13 ` Michael Bellion and Thomas Heinz
2003-08-03 18:14 ` jamal
2003-08-04 13:17 ` Michael Bellion and Thomas Heinz
2003-08-04 15:51 ` jamal
2003-08-05 22:21 ` Michael Bellion and Thomas Heinz
2003-08-07 19:58 ` jamal
2003-08-07 20:05 ` David S. Miller [this message]
2003-08-08 21:51 ` jamal
2003-08-09 0:01 ` David S. Miller
2003-08-11 22:39 ` Michael Bellion and Thomas Heinz
2003-08-12 2:57 ` jamal
2003-08-12 14:56 ` Michael Bellion and Thomas Heinz
2003-08-12 15:41 ` jamal
2003-08-12 5:40 ` David S. Miller
2003-08-12 14:29 ` Jamie Lokier
2003-08-12 15:39 ` Michael Bellion and Thomas Heinz
2003-08-15 14:28 ` Jamie Lokier
2003-08-13 17:28 ` Ralph Doncaster
2003-08-13 19:17 ` Jamie Lokier
2003-08-13 21:10 ` Ralph Doncaster
2003-08-13 23:21 ` Jamie Lokier
2003-08-12 14:56 ` Michael Bellion and Thomas Heinz
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=20030807130502.4af9c815.davem@redhat.com \
--to=davem@redhat.com \
--cc=hadi@cyberus.ca \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=nf@hipac.org \
/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).