DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Abdul, Jaffar" <jabdul@ciena.com>
To: Matthew Hall <mhall@mhcomputing.net>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK Hash library
Date: Thu, 2 Jul 2015 17:02:32 -0400	[thread overview]
Message-ID: <23903483D1A9B04AB5D759C6C845237F042C494356@ONWVEXCHMB05.ciena.com> (raw)
In-Reply-To: <20150702192638.GA4663@mhcomputing.net>

HI

Thanks guys for helping me on this one! Your suggestions are very good and it is very helpful!

Thanks
Jaffar


-----Original Message-----
From: Matthew Hall [mailto:mhall@mhcomputing.net] 
Sent: Thursday, July 02, 2015 12:27 PM
To: De Lara Guarch, Pablo
Cc: Abdul, Jaffar; Richardson, Bruce; dev@dpdk.org
Subject: Re: [dpdk-dev] DPDK Hash library

On Thu, Jul 02, 2015 at 05:55:20PM +0000, De Lara Guarch, Pablo wrote:
> You are probably talking about extendable buckets here.
> The downsize of that approach is that you have to allocate memory on 
> the fly, whereas with the cuckoo hash implementation, the entry can be 
> stored in an alternative bucket without having to reserve more memory (which also will take you more time).
> With this approach, hash tables can get a higher utilization, as other 
> less used buckets can be used to store keys from other busier buckets.
> 
> Pablo

Expanding and shrinking buckets constantly can also be concurrency-hostile, and is a lot more complicated to get right than just using a good rehash algorithm and a nice static hunk of memory on contiguous hugepages for minimal TLB / cache pressure.

If you want to do these more complex manipulations uthash is probably a better route. But it will be slower than the DPDK hashes by quite a ways I think. I used DPDK hash for my TCP socket table where everything is a very predictable size, but I had to use uthash for my unpredictably sized byte buffers for security indicators (IP, URL, Domain, Email, File Hash, etc.)

Of course, when you do this kind of stuff in your app it is going to give you scaling problems and you'll have to spend a lot of time tuning it.

Matthew.

      reply	other threads:[~2015-07-02 21:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-01 23:56 Abdul, Jaffar
2015-07-02  9:36 ` Bruce Richardson
2015-07-02 11:20   ` Dumitrescu, Cristian
2015-07-02 16:30     ` Matthew Hall
2015-07-02 17:37   ` Abdul, Jaffar
2015-07-02 17:55     ` De Lara Guarch, Pablo
2015-07-02 19:26       ` Matthew Hall
2015-07-02 21:02         ` Abdul, Jaffar [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=23903483D1A9B04AB5D759C6C845237F042C494356@ONWVEXCHMB05.ciena.com \
    --to=jabdul@ciena.com \
    --cc=dev@dpdk.org \
    --cc=mhall@mhcomputing.net \
    --cc=pablo.de.lara.guarch@intel.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).