From owner-freebsd-net Wed Apr 26 14: 2: 6 2000 Delivered-To: freebsd-net@freebsd.org Received: from luxren2.boostworks.com (luxren2.boostworks.com [194.167.81.214]) by hub.freebsd.org (Postfix) with ESMTP id C0D2437BBC3; Wed, 26 Apr 2000 14:01:56 -0700 (PDT) (envelope-from root@boostworks.com) Received: from boostworks.com (root@oldrn.luxdev.boostworks.com [192.168.1.99]) by luxren2.boostworks.com (8.9.1/8.9.1) with ESMTP id XAA45605; Wed, 26 Apr 2000 23:01:24 +0200 (CEST) Message-Id: <200004262101.XAA45605@luxren2.boostworks.com> Date: Wed, 26 Apr 2000 23:01:33 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@boostworks.com Subject: Re: Proposal for ethernet, bridging, netgraph To: csg@waterspout.com Cc: archie@whistle.com, luigi@FreeBSD.ORG, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG In-Reply-To: <20000426153100.A1623@waterspout.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26 Apr, C. Stephen Gunn wrote: > On Wed, Apr 26, 2000 at 12:19:42PM +0200, Remy Nonnenmacher wrote: > >> Well but the tricky thing is the bdg_forward() function. As it may be >> called from the if_xx codes and from ether_output(), the work implied >> will be probably a lot more important than delaying the ether header >> ripping after the bridging in ether_input(). > > But bridging is a layer-2 operation. Shouldn't it happen with the > layer-2 processing, not in the driver for the physical device? Yes. That's why Archie initially proposed to rework this. > > I don't think this is the direction FreeBSD should be headed: > > Hey! My IP Stack gets faster if I educate if_ti.c about the > protocol-socket interface and have it do all the dirty work at > splnet(). Now we get to maintain TCP/IP two places in the kernel. > In the mean time, you must keep in mind some trends, like ether chips off-load IP checksums flying around, need to match sessions as soon as possible for filtering/forwarding, etc... never heard about 'active networks' ? >> 1) create an ether_input2() that {bpf_tap(), brige(), m_adj(); >> ether_input()} >> 2) Call ether_input2() from any simple drivers doing the ripping. >> 3) keep all 'strange' or not-reviewed drivers using the standard >> ether_input() >> 4) carefully move all these drivers needing review to ether_input2() >> 5) merge ether_input2 into ether_input when there will be no more >> driver using the standard ether_input. > > Isn't that what Archie has been doing? Couldn't this entire > migration take place _now_ as a patchkit before bringing in any > new special-purpose functions to the kernel? > Until the problem of where the ether header ripping takes place is solved, we can hardly move forward. Anyway, the whole rework process will however take place (and we will be soon be able to use bridging from vmware ;). RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message