From owner-freebsd-current@FreeBSD.ORG Tue May 18 09:50:03 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 083AB16A4CE; Tue, 18 May 2004 09:50:03 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AAEA43D7B; Tue, 18 May 2004 09:49:54 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i4IGnqkM034082; Tue, 18 May 2004 17:49:53 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i4IGnpON094205; Tue, 18 May 2004 17:49:52 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Harti Brandt In-Reply-To: References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> <1084885227.23208.3.camel@builder02.qubesoft.com> <20040518090647.A39810@xorpc.icir.org> Content-Type: text/plain Message-Id: <1084898991.23208.14.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 18 May 2004 17:49:51 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: Luigi Rizzo 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 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:50:03 -0000 On Tue, 2004-05-18 at 17:21, Harti Brandt wrote: > 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. Well it seems to me that IPv6 neighbour discovery is different enough from ARP that it makes sense to have IPv4-specialised ARP and IPv6-specialised ND. The only other variable is the size of the LL address and that doesn't add any significant complexity since its just moved around with bcopy.