From: Jonathan Morton <chromatix99@gmail.com>
To: Sean Conner <sean@conman.org>
Cc: bloat-devel@lists.bufferbloat.net
Subject: Re: A tiny almost sorta kinda nearly minimal perfect hash for a mac classifier?
Date: Tue, 15 Nov 2011 23:44:25 +0200 [thread overview]
Message-ID: <3879FC19-038C-49FB-9C83-6D2F1EFCE56A@gmail.com> (raw)
In-Reply-To: <20111115211416.GA12236@brevard.conman.org>
On 15 Nov, 2011, at 11:14 pm, Sean Conner wrote:
> It was thus said that the Great Dave Taht once stated:
>>
>> 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.
>
> More on this. Now that I'm at the office, I can scan a larger selection
> of MAC addresses. Out of the 38 machines currently on the segment, the
> lower twelve bits of each MAC addresses are unique (this excluding broadcast
> and multicast MAC addresses).
>
>> Does anything elegant exist? Anything worthy in the kernel?
>
> For non-broadcast/multicast MAC addresses, take the last N bits.
For 16 bits, the birthday theorem predicts a 50% chance of at least one collision when there are 256 hosts. Dave wants to scale up to 2048 hosts. So consider the following:
uint32_t upper = (mac >> 16) & MASK;
uint16_t hash = 0xFFFF & (mac ^ ((upper << X)|(upper >> (32-X))) ^ ((upper << Y)|(upper >> (32-Y))));
When a collision is detected on a new MAC, X and Y can be searched in the 0..31 space for a combination with minimal collisions (probably zero). When X and Y are equal, that is equivalent to taking the bottom 16 bits. The rotate operations are usually compiled to single instructions on modern CPUs and halfway competent compilers, and the available unique combinations of X and Y are normally over 490, giving a fairly good defence against the birthday theorem.
Of course, some of the 16-bit subsets of the MAC probably have low entropy, especially if an organisation has bought a lot of network hardware from the same vendor, but hopefully that doesn't matter in practice.
- Jonathan Morton
next prev parent reply other threads:[~2011-11-15 21:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-13 20:43 Dave Taht
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 [this message]
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=3879FC19-038C-49FB-9C83-6D2F1EFCE56A@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=sean@conman.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