From owner-freebsd-current@FreeBSD.ORG Tue May 18 09:21:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C06AD16A4CE; Tue, 18 May 2004 09:21:43 -0700 (PDT) Received: from n33.kp.t-systems-sfr.com (n33.kp.t-systems-sfr.com [129.247.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E21B43D1F; Tue, 18 May 2004 09:21:42 -0700 (PDT) (envelope-from harti@freebsd.org) Received: from n81.sp.op.dlr.de (n81g.sp.op.dlr.de [129.247.163.1]) i4IGLMj71962; Tue, 18 May 2004 18:21:22 +0200 Received: from zeus.nt.op.dlr.de (zeus.nt.op.dlr.de [129.247.173.3]) by n81.sp.op.dlr.de (AIX5.1/8.11.6p2/8.11.0) with ESMTP id i4IGLMK153506; Tue, 18 May 2004 18:21:22 +0200 Received: from localhost (brandt@localhost) by zeus.nt.op.dlr.de (8.11.7+Sun/8.9.1) with ESMTP id i4IGLH816254; Tue, 18 May 2004 18:21:17 +0200 (MET DST) X-Authentication-Warning: zeus.nt.op.dlr.de: brandt owned process doing -bs Date: Tue, 18 May 2004 18:21:17 +0200 (MET DST) From: Harti Brandt X-X-Sender: brandt@zeus To: Luigi Rizzo In-Reply-To: <20040518090647.A39810@xorpc.icir.org> Message-ID: References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> <20040518090647.A39810@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: net@freebsd.org Subject: Re: new arp code snapshot for review... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2004 16:21:43 -0000 On Tue, 18 May 2004, Luigi Rizzo wrote: LR>On Tue, May 18, 2004 at 02:00:28PM +0100, Doug Rabson wrote: LR>> On Tue, 2004-05-18 at 09:48, Luigi Rizzo wrote: LR>> > I will try to remove as many assumptions as possible. LR>> > thanks for the feedback. LR>> LR>> I think that in your prototype, the only assumption was in struct LR>> llentry. I would suggest defining it as something like: LR> LR>to be really flexible, both l3_addr and ll_addr should be LR>variable size (v4,v6,v8 over 802.x,firewire,appletalk,snail-mail), LR>then things rapidly become confusing and inefficient. LR>I would like to keep the ipv4 over ethernet case simple and quick, even LR>if this means replicating the code for the generic case (and this LR>is one of the reasons i have stalled a bit on this code -- i want LR>to make up my mind on what is a reasonable approaxch). The most common use of that table is to have an l3_addr and search the ll_addr, right? In that case making ll_addr variable shouldn't have a measurable influence on speed. Variable l3_addr could be different though. harti