From owner-freebsd-hackers Tue Mar 4 13:09:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA15964 for hackers-outgoing; Tue, 4 Mar 1997 13:09:48 -0800 (PST) Received: from wong.rogerswave.ca (wong.rogerswave.ca [204.92.17.32]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA15959 for ; Tue, 4 Mar 1997 13:09:45 -0800 (PST) Received: (from wong@localhost) by wong.rogerswave.ca (8.8.5/8.7.3) id VAA00436; Mon, 3 Mar 1997 21:19:44 -0500 (EST) Date: Mon, 3 Mar 1997 21:19:39 -0500 (EST) From: Ken Wong X-Sender: wong@wong.rogerswave.ca Reply-To: wong@rogerswave.ca To: Alan Cox cc: davem@jenolan.rutgers.edu, imb@scgt.oz.au, dg@root.com, netdev@roxanne.nuclecu.unam.mx, hackers@freebsd.org Subject: Re: ok, final sockhash changes, new diff In-Reply-To: <199703022238.WAA23129@snowcrash.cymru.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 2 Mar 1997, Alan Cox wrote: > I talked to a few dynamic "perfect has" folks a while ago. They all said > overhead of recomputation of the hash was too high. actually, this paper by Larson talks about the hash table with n items in each packet. when the packet axceed n items, it double its table size. Note that in most app, growth shouldn't happen often. however, if overhead is the problem, you can modify the algo a little to search said item k, if the design item is not in k, then search k/2 (asume that you know that to grow the table is doubling the table size). and if found re-insert it in k... Ken