Date: Thu, 27 Apr 2000 13:32:15 +0200 From: Andre Oppermann <oppermann@pipeline.ch> To: Larry Lile <lile@stdio.com> Cc: freebsd-net@freebsd.org, Archie Cobbs <archie@whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <3908253F.98A0B55C@pipeline.ch> References: <Pine.BSF.4.05.10004262233520.64956-100000@heathers.stdio.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Larry Lile wrote: > > 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. If this is becoming a general input packet handling routine then please don't call it ether_input() anymore. Maybe packet_input() is suitable name. > 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... If we are discussing such deep changes we IMHO we should look at the big picture and take also a replacement of the current (ethernet specific) ARP code with NetBSD's into consideration: http://www.daemonnews.org/199809/underhood.html I certainly would volunteer to port it from NetBSD to FreeBSD but that would be my first coding dive into the network stack. > 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. See my comments. -- Andre AO6-RIPE/AO137 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?3908253F.98A0B55C>