Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Apr 2000 15:31:00 -0500
From:      "C. Stephen Gunn" <csg@waterspout.com>
To:        Remy Nonnenmacher <remy@boostworks.com>
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>
In-Reply-To: <200004261019.MAA43188@luxren2.boostworks.com>; from remy@boostworks.com on Wed, Apr 26, 2000 at 12:19:42PM %2B0200
References:  <200004260055.RAA55462@bubba.whistle.com> <200004261019.MAA43188@luxren2.boostworks.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000426153100.A1623>