From owner-freebsd-net Wed Apr 26 19:49:27 2000 Delivered-To: freebsd-net@freebsd.org Received: from heathers.stdio.com (heathers.stdio.com [199.89.192.5]) by hub.freebsd.org (Postfix) with ESMTP id E500937BB29 for ; Wed, 26 Apr 2000 19:49:22 -0700 (PDT) (envelope-from lile@stdio.com) Received: from heathers (heathers [199.89.192.5]) by heathers.stdio.com (8.9.3/8.8.8) with ESMTP id WAA72382; Wed, 26 Apr 2000 22:49:22 -0400 (EDT) (envelope-from lile@stdio.com) Date: Wed, 26 Apr 2000 22:49:21 -0400 (EDT) From: Larry Lile To: freebsd-net@freebsd.org Cc: Archie Cobbs Subject: Re: Proposal for ethernet, bridging, netgraph In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org After reading along with this thread I thought I might point out a way for us to further reduce redundant code in the network stack. It would allow any driver token-ring, atm, ethernet, ... to use ether_input directly without having to either replicate the code or fake ethernet headers. So after discussing this with Archie he thought I should post it to -net. So here goes, please feel free to make suggestions or comments. Currently ethernet drivers call ether_input(ifp, eh, m) and the token-ring driver calls iso88025_input(ifp, th, m). The two functions are orthoganal. The real difference is how you arrive at ether_type. So ether_input & iso88025_input are basically a big switch that moves the packet into the appropriate stack. What has been suggested is moving the bpf & bridging code into ether_input. That is fine for ethernet drivers, but it does little or nothing for non-ethernet drivers. The only real reason that it can't be used for other devices is that it can't find the ether_type for non-ethernet frames. The llc gunk should be moved out of ether_input and into a seperate function that calls ether_input when neccesary. People have been going round and round about where to store the link-level (mac/dlc) header. Applications have generally made the broken assumption that the mac header starts 14 bytes before the data. This is true for ethernet but not everything :-( There is a field in the mbufs just for this, m->m_pkthdr.header. This is how I recover source-routing data for arp. All of the ethernet drivers set it to NULL. If all the drivers set m->m_pkthdr.header to point to the mac header then every layer would know where to find it and there would be no need to pass "eh" into ether_input. If m->m_pkthdr.header is set correctly then all of the upper layers automatically have access to the mac header, no matter what the interface type is or where the header physically resides. This could also be helpful for tcpdump, dhcp, arp, bridging... So what I was proposing is change ether_input(ifp, eh, m) to ether_input(struct *ifnet, u_short ether_type, struct mbuf *m). Anyone who needs to know how to interpret the mac header from this point on/up should be able do it using ifp->if_type.if_data.ifi_type. For instance ether_input only uses the mac header to keep track of the number of multicast packets and broadcasts. Then you hit the switch(ether_type) which goes into the upper layers. The llc code should be split out (and down). It would look like this: Remove Remove llc MAC header header. +------+ +-----------+ Route packets | oltr |--llc->| llc_input |\ based on ether_type +------+\ +-----------+ | +-------------+ [bridge] Remove \--non-llc---------+------>| ether_input | - ->[netgraph] MAC header | +-------------+ [vlan] +------+ | (ether_type) | ed |--------------------/ / | | \ \ +------+ / [arp][ip][ipv6][ipx][...] | fddi |----------------/ (may need llc?) +------+ / | atm |------------/ (may need llc?) +------+ By Removing the * header, I mean adjusting m_data, m_len, m_pkthdr.len, ... Not actually destroying them. Of course this is assuming the neccesary changes for the bridge code being moved in to ether_input. I don't see a need to add link headers, length, ... in the call to ether_input that is why ifi_type and m_pkthdr.* exist. Currently the network stack is way too ethernet-centric, but then I guess there is a lot of ethernet in the world :-) I will save my comments about ether_output and the arp code until later, but they should be modified in a similar fashion. -- Larry Lile lile@stdio.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message