From owner-freebsd-net@FreeBSD.ORG Sun Sep 5 21:53:44 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B80BD16A4CE for ; Sun, 5 Sep 2004 21:53:44 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2FBA43D48 for ; Sun, 5 Sep 2004 21:53:43 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26414 invoked from network); 5 Sep 2004 21:50:42 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Sep 2004 21:50:42 -0000 Message-ID: <413B8AE7.F211C23@freebsd.org> Date: Sun, 05 Sep 2004 23:53:43 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20040905205249.GA81337@cell.sick.ru> <20040905213823.GA81610@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Luigi Rizzo cc: hackers@freebsd.org cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2004 21:53:45 -0000 Gleb Smirnoff wrote: > > On Sun, Sep 05, 2004 at 02:20:36PM -0700, Luigi Rizzo wrote: > L> > I see that bridge callbacks are still living in if_ed.c > L> > from FreeBSD 2.x times. See if_ed.c:2816. I think this is > L> > not correct. > L> > > L> > Bridge code is called from ether_input(), which is > L> > indirectly called from if_ed.c:2836. > L> > > L> > Any objections about attached patch? > L> > L> there are performance reasons to do this way -- grabbing > L> the entire packet is expensive because it is done via programmed > L> I/O, so the current code only grabs the header, does the > L> filtering, and grabs the rest of the packet only if > L> needed. > > Well, what percentage of packets is usually dropped by bridge in > normal operation? Performance degradation applies only to them. That depends on how many systems are behind the bridge. Every packet not needing to go to the other side is dropped. > L> Probably the current code runs bridge_in_ptr() twice, but I > L> believe this is still cheaper than grabbing all packets > L> entirely. > L> I'd rather not apply the patch unless you can show that > L> the current code leads to incorrect behaviour. > > The problem is with layer intermixing. ed(4) is a device > driver, it must pass its frames to Ethernet stack > without any hacks. By the way ed(4) is the only driver > which does this. Yes. And I fully agree with Matt here. Nobody in their right mind would use ed(4) for *anything* these days. The best would probably to remove ed(4) alltogether. (Only half kidding). I fully support removing this hack from ed(4) to get the API right again. *If* someone is actually affected by this I'm going to buy him a shiny fxp card off Ebay for $3.59. I don't want to offend Luigi at all but the times are over to support such major layering violations these days for such an obscure piece of hardware. This 6-current now and we don't even support 386 CPUs anymore. > Actually I'm working on the problem decribed here > > http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-May/003881.html > > and one of the approaches I'm considering is to push the > block (lines 569-615) from if_ethersubr.c into bridge.c. This > probably requires small changes to bridge_in()/bdg_forward() > logic, so it's caller must take care. We have only two callers > now - ether_input(), which is OK and if_ed, which looks like > a hack. I'm not sure if I can follow the graph correctly. Shouldn't the straight line between where ng_ether_input and ng_ether_rcvdata branch be disconnected? The way it is drawn there looks like the packet is arrving double in the upper half? > P.S. Sam said, that there are plans to convert bridge to use pfil-hooks. > If this happens, the code in if_ed.c will be on the way again. No. What will move to pfil_hooks is the firewalling within the bridge code and the layer2 ethernet firewalling. The bridging code as such will stay where it is. -- Andre