Date: Sun, 23 Apr 2000 21:29:42 -0500 From: "C. Stephen Gunn" <csg@waterspout.com> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-net@freebsd.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000423212942.A5453@waterspout.com> In-Reply-To: <200004230411.VAA17652@bubba.whistle.com>; from archie@whistle.com on Sat, Apr 22, 2000 at 09:11:45PM -0700 References: <200004230411.VAA17652@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 22, 2000 at 09:11:45PM -0700, Archie Cobbs wrote: > So, I've got a proposal :-) These are not all my ideas, but > here they are collected in one place.. It's good to see someone else has been pondering these issues. If the goal is to overhaul the networking code in FreeBSD, we should spend significant time planning, and researching other solutions to the improvements we want. > 1 Move the BPF and BRIDGE code out of all of the Ethernet drivers > and put it into ether_input() I brought up some discussion on doing exactly this a few weeks ago. To quote Garrett Wollman "go for it." > 2 Add a new parameter to ether_input() which a driver will set > to non-zero indicating ``IFF_PROMISC was set and this packet > came in, but it's not really supposed to be received so don't > send it up the networking stack.'' While Ethernet is certainly the most popular packet network interface that people use on FreeBSD. I'd rather see the API for all layer-1 and layer-2 devices converge. ether_input(), token_input(), atm_input() and media_input() should certainly be orthogonal, if not identical. For any given media, assuming your suggestion [#1], media_input() would take a pointer to the device structure, and a mbuf chain containing the packet, with the link-layer header intact. media_input() should handle BPF taps, remove the link-header if appropriate, and then route the packet up to one of the registered layer-2 protocols. I think anything outside this should be in the device flags. I'm voting to have flags in struct ifnet that apply to _ANY_ device, and another media flags for each specific link layer. The default behavior for any given device should be to present itself to userland just like it always have. I plug in a 3c905B-TX card, and I still end up with an xl device. Assuming, I've not done something more advanced with the configuration. You mention this below in [#4]. Since deletion of interfaces works now, there are some significant advantages of having an generic "media-like" interface. This could be used for more advanced configs like Bridging and VLANs. It should allow for aggregation/bonding of interfaces, and perhaps get something like Cisco-ISL or Fast EtherChannel in there as well. > 3 Move the netgraph part of if_ethersubr.c into a new file ng_ether.c > and make it so the Ethernet node type can be a KLD and still work. Sounds good to me. > 4 Change the ng_ether node type to have these two hooks: > "device" -- connection down to the raw Ethernet device > "stack" -- connection to the Ethernet stack and upper stacks ng_ether would seem to be a good starting point for any ethernet-like interface on top of a group of (or logical seperation of) physical interfaces. > 5 Add netgraph control messages to get the associated interface name > and index, so that it's possible to set promiscuous mode, multicast > addresses, etc. by: > from the kernel - getting the interface structure (using > ifindex2ifnet[if_index]), and then calling ifioctl() > (small note: ifioctl() will be made to handle p == NULL) > from userland - using the normal ioctl() mechanism Mmm.. Cleaning out the "garbage can of system calls" eh? > 6 Minor fix to ppp(8), etc. to handle different ng_ether hook names > > Re #4: When neither hook is connected, they are effectively connected > together -- i.e., the interface functions normally. Otherwise, you > get the obvious data connection, allowing both sending and recieving > raw frames to the device, but also input/output from the Ethernet > stack associated with the interface. Filtering Ethernet frames based > on interface would be easy .. etherfw(8) anyone? :-) That's one of the obvious advantages to a more-complete netgraph deployment in the kernel. Filtering/tapping packet flows nearly anywhere in the kernel. Drool... > 6 Convert BRIDGE into a netgraph node. This would make it more > powerful because you could do bridging on any arbitrary subset > of interfaces. Its a logical step. > 7 (Optional) Remove existing BRIDGE support in favor of netgraph version > Only if people want to for simplicity. I'd have no problems with this, providing the rest of it works well of course. It's appropriately at the end of your list. I've got a few daydreams to add to your list: - Appropriate improvements to other media types to keep them up to speed with the improvements made to ethernet. - Planning for, if not the implementation of run-time loadable protocol stacks. I'm not entirely sure what all this involves, but it minimally requires an API to register a protocol with each media handler. Hello? I'm the tcp/ip stack that joe-user just loaded, send me ethernet frames with a ether_type of ETHERTYPE_IP. Nope, don't need a copy of the link header. Oh by the way, I need ARP, so load up my bud as well. Time to go register with ATM or other physical/link layer devices I know how to talk to. I know this will require some rework on the protocol-socket interface as well, but that's certainly not my forte. - Like you said above, a generic filter module for netgraph. Something that's more efficient thatn IPFW. Perhaps something that has a compiler for the filter language. - Alternate queing mechanisms. Something like the fair weighted queue's that Luigi has on his experiments page. Make sure we support bonded/shared interfaces well. Have support for priority tags with 802.1q or the like. 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?20000423212942.A5453>