From owner-freebsd-arch@FreeBSD.ORG Sun Jan 6 21:41:04 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF72C16A41B for ; Sun, 6 Jan 2008 21:41:04 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 33F0313C45D for ; Sun, 6 Jan 2008 21:41:03 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 84605 invoked from network); 6 Jan 2008 21:05:35 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 6 Jan 2008 21:05:35 -0000 Message-ID: <47814AF0.9070509@freebsd.org> Date: Sun, 06 Jan 2008 22:41:04 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Vadim Goncharov References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , arch@freebsd.org, Ivo Vachkov , Robert Watson , Julian Elischer , "Bruce M. Simpson" Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 21:41:04 -0000 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. -- Andre