From owner-freebsd-net Wed Apr 26 13:22:11 2000 Delivered-To: freebsd-net@freebsd.org Received: from dustdevil.waterspout.com (fourier.physics.purdue.edu [128.210.146.43]) by hub.freebsd.org (Postfix) with ESMTP id 45BFE37B72A; Wed, 26 Apr 2000 13:22:05 -0700 (PDT) (envelope-from csg@dustdevil.waterspout.com) Received: (from csg@localhost) by dustdevil.waterspout.com (8.9.3/8.9.3) id PAA01699; Wed, 26 Apr 2000 15:31:00 -0500 (EST) (envelope-from csg) Date: Wed, 26 Apr 2000 15:31:00 -0500 From: "C. Stephen Gunn" To: Remy Nonnenmacher Cc: archie@whistle.com, luigi@FreeBSD.ORG, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000426153100.A1623@waterspout.com> References: <200004260055.RAA55462@bubba.whistle.com> <200004261019.MAA43188@luxren2.boostworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004261019.MAA43188@luxren2.boostworks.com>; from remy@boostworks.com on Wed, Apr 26, 2000 at 12:19:42PM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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? 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. > 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? - Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message