public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Brian F. G. Bidulock" <bidulock@openss7.org>
To: Raghuram <draghuram@rocketmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Question about tcp hash function tcp_hashfn()
Date: Tue, 30 May 2006 23:55:26 -0600	[thread overview]
Message-ID: <20060530235525.A30563@openss7.org> (raw)
In-Reply-To: <20060531042908.10463.qmail@web51410.mail.yahoo.com>; from draghuram@rocketmail.com on Tue, May 30, 2006 at 09:29:08PM -0700

Raghuram,

On Tue, 30 May 2006, Raghuram wrote:

> 
> Hi,
> 
> I needed a hash function (in my TCP related work) for
> a project and happened to look at the function used by
> TCP implementation in Linux. I searched for some
> information about this function but couldn't find much
> info. I would appreciate it if someone can provide
> details or some pointers in this regard. Specifically,
> 
> 
> 1) Are there some design considerations/assumptions
> behind the algorithm? In general, how was the
> algorithm arrived at?

If you mean tcp_hashfn() from 2.4 kernel, I don't believe so.
In fact, if you analyze it, it is not even a very good nor
efficient hash function.  For example, it goes to great pains
to permute upper order bits in the local address, which for
most connections will be a constant value.

> 2) What happens if there are collisions? I am assuming
> that each entry in the array will point to a linked
> list of structures. Is there any limit on the length
> of this list? 

The hash value is used to index a hash bucket that has
established TCP sockets attached in a linked (collision)
list.  Because the number of input values is limited, the
number of collisions is bounded.  What the actual bound is
can be determined by analysis or using numerical methods.

Because local address has an extremely limited range, local
port number has a limited range (for dynamic assigment) and
the maximum number of connections will be limited by other
factors (e.g. system maximum number of open file descriptors)
the practical bound is much smaller than the theoretical bound
on the length of the collision list.  Because it is not a very
good hash function, the bound on collisions for a given range
of input values might be greater than if a better function were
used.  Also, TCP allocates rather large connection hash tables
at startup further reducing the size of collision lists.

There are two typcial uses of TCP: well known port numbers
upon which listening servers exist and outgoing client connections.
Outgoing client connections will almost always use a unique port
number.  The hash function does not really exploit this fact.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

  reply	other threads:[~2006-05-31  5:55 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-31  4:29 Question about tcp hash function tcp_hashfn() Raghuram
2006-05-31  5:55 ` Brian F. G. Bidulock [this message]
2006-05-31  7:10   ` David Miller
2006-05-31  7:45     ` Brian F. G. Bidulock
2006-05-31  7:49       ` David Miller
2006-05-31  8:00         ` Brian F. G. Bidulock
2006-05-31  9:03           ` Evgeniy Polyakov
2006-05-31  9:12             ` David Miller
2006-05-31  9:44               ` Evgeniy Polyakov
2006-05-31  9:51             ` Brian F. G. Bidulock
2006-05-31 10:58               ` Evgeniy Polyakov
2006-05-31 11:04                 ` Evgeniy Polyakov
2006-05-31 13:06                   ` Evgeniy Polyakov
2006-05-31 18:29                     ` Brian F. G. Bidulock
2006-06-01  6:12                       ` Evgeniy Polyakov
2006-06-01  6:18                         ` David Miller
2006-06-01  6:22                           ` Brian F. G. Bidulock
2006-06-01  6:24                             ` David Miller
2006-05-31 18:41                 ` David Miller
2006-06-01  6:04                   ` Evgeniy Polyakov
2006-06-01  6:18                     ` Brian F. G. Bidulock
2006-06-01  6:30                       ` Evgeniy Polyakov
2006-06-01  6:46                         ` Brian F. G. Bidulock
2006-06-01  7:01                           ` Evgeniy Polyakov
2006-06-01  7:11                             ` Brian F. G. Bidulock
2006-06-01  8:38                               ` Evgeniy Polyakov
2006-06-01 10:24                                 ` Brian F. G. Bidulock
2006-06-01 11:06                                   ` Evgeniy Polyakov
2006-06-01 18:40                                     ` Brian F. G. Bidulock
2006-06-01 20:21                                       ` David Miller
2006-06-02  7:01                                       ` Evgeniy Polyakov
2006-06-02  5:40                     ` Florian Weimer
2006-06-02  7:48                       ` Evgeniy Polyakov
2006-06-02 15:10                         ` Brian F. G. Bidulock
2006-06-02 17:26                         ` Florian Weimer
2006-06-02 17:37                           ` Brian F. G. Bidulock
2006-05-31  9:52             ` Brian F. G. Bidulock
2006-05-31  8:49         ` Brian F. G. Bidulock
2006-05-31  9:02           ` David Miller
2006-05-31  9:39             ` Brian F. G. Bidulock

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=20060530235525.A30563@openss7.org \
    --to=bidulock@openss7.org \
    --cc=draghuram@rocketmail.com \
    --cc=linux-kernel@vger.kernel.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