> > Why a full walk, why such a dumb way? > Correct, we don't do a full walk.
> > 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. > Is it really a double lookup though ? With the current routing table that contains the ARP entries, a search has to proceed pass the interface route further down the routing tree, and the depth depends on the number of ARP 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, 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 > 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. > No disagreement here. -- Qing _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
