Date: Tue, 18 May 2004 18:21:17 +0200 (MET DST) From: Harti Brandt <harti@freebsd.org> To: Luigi Rizzo <rizzo@icir.org> Cc: net@freebsd.org Subject: Re: new arp code snapshot for review... Message-ID: <Pine.GSO.4.60.0405181817030.16008@zeus> In-Reply-To: <20040518090647.A39810@xorpc.icir.org> References: <20040425094940.A50968@xorpc.icir.org> <200405162013.33894.dfr@nlsystems.com> <20040518014828.B2380@xorpc.icir.org> <20040518090647.A39810@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.60.0405181817030.16008>