Date: Sun, 05 Sep 2004 23:53:43 +0200 From: Andre Oppermann <andre@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? Message-ID: <413B8AE7.F211C23@freebsd.org> References: <20040905205249.GA81337@cell.sick.ru> <20040905213823.GA81610@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?413B8AE7.F211C23>