Date: Wed, 09 Jan 2008 00:29:28 +0600 From: "Vadim Goncharov" <vadimnuclight@tpu.ru> To: "Andre Oppermann" <andre@freebsd.org> Cc: Qing Li <qingli@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, arch@freebsd.org, Ivo Vachkov <ivo.vachkov@gmail.com>, Robert Watson <rwatson@freebsd.org>, Julian Elischer <julian@elischer.org>, "Bruce M. Simpson" <bms@freebsd.org> Subject: Re: resend: multiple routing table roadmap (format fix) Message-ID: <opt4mizese4fjv08@nuclight.avtf.net> In-Reply-To: <47814AF0.9070509@freebsd.org> References: <4772F123.5030303@elischer.org> <f85d6aa70712261728h331eadb8p205d350dc7fb7f4c@mail.gmail.com> <477416CC.4090906@elischer.org> <opt4c0imk24fjv08@nuclight.avtf.net> <477D2EF3.2060909@elischer.org> <opt4g4kcis17d6mn@nuclight.avtf.net> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> <opt4i0rlz317d6mn@nuclight.avtf.net> <47814AF0.9070509@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
07.01.08 @ 03:41 Andre Oppermann wrote: > Vadim Goncharov wrote: >> 07.01.08 @ 00:10 Julian Elischer wrote: >> >>>>> Is multicast and multipath routing the same? >>>> No. They are currently orthogonal. >>>> However it makes sense to merge the multicast and unicast forwarding >>>> code as currently MROUTING is limited to a fan-out of 32 next-hops >>>> only. In multicast, next-hops are normally just interfaces. >>>> Also the IETF MANET ad-hoc IP is going to need hooks there; >>>> multicast in MANET needs to address its next-hops by their unicast >>>> address, and encapsulate the traffic with a header. This is not true >>>> link layer multicast -- although it might use link layer multicast to >>>> leverage the hash filters in 802.11 MACs. >>>> As regards getting ARP out of forwarding tables, this should have >>>> happened a long time ago... >>> >>> I'm not 100 % convinced of this... >>> I was, but I think there may still be a place for a cached arp pointer >>> in hte next hop route to the arp entry for that next hop. >>> I DO however thing that the arp stuff should nto be accessing its >>> data via the routing table. >> Surely, routing table should contain a cached pointer to an entry in >> L2 table (ARP in case of Ethernet), to not do double lookups. But still >> separate those tables... > > Locking hell over again. How do you remove an ARP entry without doing > a full walk over the entire routing table (some 250K entries for the > DFZ)? Make it rmlocks and be done with it. Why a full walk, why such a dumb way? To remove an ARP entry for host A.B.C.D in L2 table of form (A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed) routing lookup for host A.B.C.D and modify a one pointer in it's rtentry to NULL or remove rtentry (if it's selected to be implemented as cloned). Thus, when on regular forwarding (table read) a routing lookup is done, we already have a FAST access - one pointer dereference - for it's L2 table entry, be it ARP or any other L2 type (which support becoming easily with separation of L2 and L3). And on every modification of L2 table - which is RARE - do lookup with usual speed to modify cached pointer. Compare it with a scheme where for EVERY forwarded packet, there is a need for DOUBLE lookup - after a routing one, do another in L2 table. Current routing table implementation, with all disadvantages of combining L2 and L3, have from the same combinig a one HUGE benefit - performance. And never, ever, ever, ever even try to split L2 from L3 with losing that performance - then it should be still never split, despite all disadvantages, and you'll become an enemy of many, many users. Especially while caching allows to do things reasonably fast. -- WBR, Vadim Goncharov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opt4mizese4fjv08>