Date: Wed, 26 Apr 2000 23:01:33 +0200 (CEST) From: Remy Nonnenmacher <remy@boostworks.com> 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 Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <200004262101.XAA45605@luxren2.boostworks.com> In-Reply-To: <20000426153100.A1623@waterspout.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004262101.XAA45605>