From: Dave Taht <dave.taht@gmail.com>
To: bloat-devel <bloat-devel@lists.bufferbloat.net>
Subject: A tiny almost sorta kinda nearly minimal perfect hash for a mac classifier?
Date: Sun, 13 Nov 2011 21:43:59 +0100 [thread overview]
Message-ID: <CAA93jw4R7YZXJAvWTeDg=VH47xzbrFudOhpKAd_4dPMHWvWTYw@mail.gmail.com> (raw)
There's this class of non-algorithms where stupid and brute force
nearly works. Then there are the be-all end-all algorithms which scale
beautifully O(1) over n - so long as n is large enough to wipe out the
overhead of the be-all-end-all algorithm, and taking locks, allocating
memory at bad times, etc, is ok.
I keep running into problems where brute force and a simple table
lookup is almost enough.
Here's one. I'd like to classify network streams so that they end up
in a unique queue[x], based on their nexthop mac address in the ip
header.
One of a small number (say, x < 2048) of queues, that needs to be
absolutely unique per mac. It's ok if 99% of the queues
are idle at any given point. It's OK if the initial classification
collides with another mac so long as eventually it doesn't.
Algo needs to be fast and lock free, relying only on a very few atomic
increment and/or swaps, only in rare cases...
On most networks today, you are usually talking to a VERY few
machines. The number of machines that appear and disappear is rather
small and stable over very long periods of time (proof: go type arp -a
on your home network)
Yet mac addresses are 48 bits wide.
Even in the case of an access point, you are never going to see more
than 2048 of them, and most APs stop at around 127 stations, and most
wireless networks have many fewer endpoints than that...
So great, I figure a mere 2 bin table lookup and random replacement
will work fine, I stuck my first attempt up at
http://www.teklibre.com/~d/mactoclass.c
and I hate it. Didn't get so far as writing garbage collection.
(double buffer it) Does anything elegant exist? Anything worthy in the
kernel?
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
next reply other threads:[~2011-11-13 20:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-13 20:43 Dave Taht [this message]
2011-11-14 2:22 ` Sean Conner
2011-11-14 2:41 ` Fred Baker
2011-11-14 7:44 ` Dave Taht
2011-11-14 8:13 ` Sean Conner
2011-11-14 8:21 ` Dave Taht
2011-11-15 21:14 ` Sean Conner
2011-11-15 21:44 ` Jonathan Morton
2011-11-15 22:19 ` Dave Taht
2011-11-15 22:20 ` Dave Taht
2011-11-14 8:20 Sean Conner
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='CAA93jw4R7YZXJAvWTeDg=VH47xzbrFudOhpKAd_4dPMHWvWTYw@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=bloat-devel@lists.bufferbloat.net \
/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