From owner-freebsd-hackers  Wed Mar  5 12:45:32 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id MAA11041
          for hackers-outgoing; Wed, 5 Mar 1997 12:45:32 -0800 (PST)
Received: from sunsite.ms.mff.cuni.cz (sunsite-atm.ms.mff.cuni.cz [194.50.23.220])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11030
          for <hackers@freebsd.org>; Wed, 5 Mar 1997 12:45:14 -0800 (PST)
Received: (from jj@localhost) by sunsite.ms.mff.cuni.cz (8.7.3/8.7.3) id VAA00601; Wed, 5 Mar 1997 21:45:07 +0100 (MET)
From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
Message-Id: <199703052045.VAA00601@sunsite.ms.mff.cuni.cz>
Subject: Re: ok, final sockhash changes, new diff
To: davem@jenolan.rutgers.edu (David S. Miller)
Date: Wed, 5 Mar 1997 21:45:07 +0100 (MET)
Cc: avalon@coombs.anu.edu.au, mingo@pc5829.hil.siemens.at, wong@rogerswave.ca,
        alan@cymru.net, imb@scgt.oz.au, dg@root.com,
        netdev@roxanne.nuclecu.unam.mx, hackers@freebsd.org
Reply-To: jj@sunsite.ms.mff.cuni.cz
In-Reply-To: <199703051354.IAA14114@jenolan.caipgeneral> from "David S. Miller" at Mar 5, 97 08:54:45 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
>    From: Darren Reed <avalon@coombs.anu.edu.au>
>    Date: Thu, 6 Mar 1997 00:45:26 +1100 (EDT)
> 
>    > Extra silly cycles in the critical code path.
> 
>    Yes, if you were doing it all the time to make sure the table was a good
>    size, but I was referring to doing it once - at boot.  (I should ahve made
>    myself more clear).
> 
> You thus have to load the power of two size of the hash table from a
> kernel variable (thus a dead cycle as far as I'm concerned) every
> lookup and furthermore every other operation on the tables.
> 
> But it is still a nice idea.  People who truly want their machine to
> scream are probably best off the configure it via a macro at compile
> time and be done with it (as per Ingo's original suggestion).

On the other side you can put there three four different routines for
different hash table sizes and thus avoid that dead cycle. Or we can use
code patching (as we already do on the sparc for other stuff).

                                                                  .u$e.
   Cheers                                                       .$$$$$:S
        Jakub                                                   $"*$/"*$$
                                                                $.`$ . ^F
                                                                4k+#+T.$F
--------------------------------------------------------------  4P+++"$"$  ---
Jakub Jelinek, jj@sunsite.mff.cuni.cz                           :R"+  t$$B
Administrator of SunSITE Czech Republic                      ___#       $$$
MFF, Charles University, Prague                              |  |       R$$k  
----------------------------------------------------------  dd. | Linux  $!$
Give your Sparc a new beginning - SparcLinux                ddd |  Sparc $9$F
--------------------------------------------------------  '!!!!!$       !!#!`
                                                           !!!!!*     .!!!!!`
                                                         '!!!!!!!W..e$$!!!!!!`
                                                          "~^^~         ^~~^