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.Received on Tue May 18 2004 - 07:50:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:54 UTC