All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Hall <mhall-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org>
To: "De Lara Guarch,
	Pablo"
	<pablo.de.lara.guarch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: Defaults for rte_hash
Date: Tue, 9 Sep 2014 13:42:52 -0700	[thread overview]
Message-ID: <20140909204252.GA11510@mhcomputing.net> (raw)
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D89722614BD2-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>

On Tue, Sep 09, 2014 at 11:42:40AM +0000, De Lara Guarch, Pablo wrote:
> That 4 is not shifted, so it is actually 4 entries/bucket. Actually, the 
> maximum number of entries you can use is 16, as bucket will be as big as a 
> cache line. However, regardless the number of entries, memory size will 
> remain the same, but using 4 entries/bucket, with 16-byte key, all keys 
> stored for a bucket will fit in a cache line, so performance looks to be 
> better in this case (although a non-optimal hash function could lead not to 
> be able to store all keys, as chances to fill a bucket are higher). Anyway, 
> for this example, 4 entries/bucket looks a good number to me.

So, a general purpose hash usually has some kind of conflict resolution when a 
bucket is full rather than just tossing out entries. It could be open 
addressing, chaining, secondary hashing, etc.

If I'm putting security indicators into a bucket and the buckets just toss 
stuff out without warning that's a security problem. Same thing could be true 
for firewall tables.

Also, if we're assuming a 16-byte key, what happens when I want to do matching 
against www.badness.com or www.this-is-a-really-long-malware-domain.net ?

Did anybody have a performant general purpose hash table for DPDK that doesn't 
have problems with bigger keys or depth issues in a bucket?

Matthew.

      parent reply	other threads:[~2014-09-09 20:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 10:31 Defaults for rte_hash Matthew Hall
     [not found] ` <20140909103153.GA7969-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org>
2014-09-09 10:45   ` Richardson, Bruce
     [not found]     ` <59AF69C657FD0841A61C55336867B5B0343EFBBD-kPTMFJFq+rELt2AQoY/u9bfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-09-09 11:42       ` De Lara Guarch, Pablo
     [not found]         ` <E115CCD9D858EF4F90C690B0DCB4D89722614BD2-kPTMFJFq+rEMvF1YICWikbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-09-09 20:42           ` Matthew Hall [this message]

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=20140909204252.GA11510@mhcomputing.net \
    --to=mhall-hv3ognyu3jfzzajbqzqcxq@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=pablo.de.lara.guarch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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 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.