From owner-freebsd-net Mon Jul 1 4:33:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5616B37B400 for ; Mon, 1 Jul 2002 04:33:19 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 0F7B043E0A for ; Mon, 1 Jul 2002 04:33:18 -0700 (PDT) (envelope-from oppermann@pipeline.ch) Received: (qmail 32855 invoked from network); 1 Jul 2002 11:32:19 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 1 Jul 2002 11:32:19 -0000 Message-ID: <3D203DAC.B32AF1A8@pipeline.ch> Date: Mon, 01 Jul 2002 13:31:56 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: ipflow_has ? References: <20020629053430.A70505@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > > Hi, > looking at the code in ip_flow.c, i notice that the hash > function ipflow_hash() uses both the source and destination > address as parameters, and additionally, it never considers > the lower two bits of the destination addres. The code is below, > IPFLOW_HASHBITS is 6: > > unsigned hash = tos; > int idx; > for (idx = 0; idx < 32; idx += IPFLOW_HASHBITS) > hash += (dst.s_addr >> (32 - idx)) + (src.s_addr >> idx); > return hash & (IPFLOW_HASHSIZE-1); > > Of course it is just an optimization, but shouldn't routing > decisions be based on the dst address only ? Routing decisions yes. But ipflow is about flows. And flows are from one IP to another. This is why both is being hashed. > Just using the dst address would slightly simplify the function, > and especially has the potential of collapsing a lot of information > in the ipflow cache -- consider the case of a router box in front > of a busy web server. If you change that please rename it to route_cache or so but no it shouldn't be called ipflow anymore then. This caching only helps in an Intranet where you have only a handful of routes. If you do Internet routing with many destinations or you have a full view then it'll make the routing slower because it is busting/cycling the cache all the time. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message