Date: Sun, 23 Apr 2000 09:11:20 +0200 (CEST) From: Luigi Rizzo <luigi@info.iet.unipi.it> To: Archie Cobbs <archie@whistle.com> Cc: pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, luigi@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <200004230711.JAA10996@info.iet.unipi.it> In-Reply-To: <200004230411.VAA17652@bubba.whistle.com> from Archie Cobbs at "Apr 22, 2000 09:11:45 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> So, I've got a proposal :-) These are not all my ideas, but
> here they are collected in one place..
Hi,
to respond to some of your ideas:
1. i fully agree on the need for putting the bpf/bridging hooks
into ether_input(), so we can avoid duplicate code when necessary.
I would actually create a new function, ether_input_something(),
which does all the stuff and then calls
the current ether_input(). The motivations would be:
- to keep the existing ether_input() unchanged;
- to let those drivers which need to be able to do some
optimizations (a case i have in mind: when doing bridging, the
'ed' driver only reads the ethernet header first, and fetches
the whole packet only if really needed. This is an important
optimization given that bridging often discards a lot of
packets and this way we save a lot of CPU/bus bandwidth).
Also I am not sure how well a generic function can deal with
special drivers (such as "de") which seem to do some
not-as-straightforward management of mbufs.
2. I am not sure if the second parm is really needed, or we should
just go ahead and check the dest.MAC address for all incoming
packets anyways. Not doing so only seems a minor optimization and
i am not even sure if passing an additional parameter and checking
if address check needs to be done is actually cheaper than doing
the 6-byte comparison right away.
But whatever...
3.-6. i still have not found the time to look into netgraph so i
cannot comment on these. I trust you that these are good ideas :)
6bis Note that even now you _can_ do bridging on arbitrary subsets of
interfaces, controlled by net.link.ether.bridge_cfg . The variable
(which is really the basis of a VLAN bridge which i am hopefully to
release in a few months) defines clusters of interfaces, and
bridging is performed separately on each cluster, and only on the
interfaces listed by that variable. Each cluster has
a numeric identifier (from 1 up) which in the VLAN version
corresponds to the VLAN ID. When the VLAN code is committed, you
will be able to define a cluster numbered 0 which is a set of TRUNK
interfaces -- packets bridged through the trunk will have the VLAN
header added/removed as required.
Speaking of etherfw(8)... somebody posted this code 1-2 months ago.
Havent committed it yet. Also, and again, some amt of filtering for
ethernet packets is already present in ipfw(8). You can
select bridged packets, and if they have IP payload also do all
ordinary tests. There is even some hack already committed which
lets you filter basing on ethernet type (for sure one needs more).
7. I would be against removing option BRIDGE as requiring netgraph
instead would probably increase the kernel footprint, and i think
a lot of people uses bridging in PicoBSD situations where memory is
a concern.
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
-----------------------------------+-------------------------------------
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?200004230711.JAA10996>