Date: Tue, 8 Jan 2008 11:03:47 -0800 From: "Li, Qing" <qing.li@bluecoat.com> To: "Vadim Goncharov" <vadimnuclight@tpu.ru>, "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: <305C539CA2F86249BF51CDCE8996AFF4096E12A7@bcs-mail2.internal.cacheflow.com> In-Reply-To: <opt4mizese4fjv08@nuclight.avtf.net> 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> <opt4mizese4fjv08@nuclight.avtf.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>=20 > Why a full walk, why such a dumb way?=20 > Correct, we don't do a full walk.=20 > > To remove an ARP entry for host A.B.C.D in L2 table of form=20 > (A.B.C.D -> 00:01:02:03:04:05), it is enough to do a (usual speed)=20 > routing lookup for host A.B.C.D and modify a one pointer in=20 > it's rtentry to NULL or remove rtentry (if it's selected to=20 > be implemented as cloned). Thus, when on regular forwarding=20 > (table read) a routing lookup is done, we already have a FAST=20 > access - one pointer dereference - for it's L2 table entry,=20 > be it ARP or any other L2 type (which support becoming easily=20 > with separation of L2 and L3). And on every modification of=20 > L2 table - which is RARE - do lookup with usual speed to=20 > modify cached pointer. Compare it with a scheme where for=20 > EVERY forwarded packet, there is a need for DOUBLE lookup -=20 > after a routing one, do another in L2 table. >=20 Is it really a double lookup though ? =20 With the current routing table that contains the ARP entries, a search has to proceed pass the interface route further down=20 the routing tree, and the depth depends on the number of ARP=20 entries in the table. With L2/L3 seperation, the routing search stops at the interface route, and further search for the exact entry continues in a separate L2 table. From a high level it does seem there could be performance issues such as cache invalidation problem, however, I cannot quantify at this point what that degration translates into,=20 and what impact it has on the overall scheme of things. I am not sure if anyone can quantify such performance question at this point. > > Current routing table implementation, with all disadvantages=20 > of combining > L2 and L3, have from the same combinig a one HUGE benefit -=20 > performance. =20 > And never, ever, ever, ever even try to split L2 from L3 with=20 > losing that performance - then it should be still never=20 > split, despite all disadvantages, and you'll become an enemy=20 > of many, many users. Especially while caching allows to do=20 > things reasonably fast. >=20 No disagreement here. -- Qing
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?305C539CA2F86249BF51CDCE8996AFF4096E12A7>