Date: Wed, 26 Apr 2000 22:49:21 -0400 (EDT) From: Larry Lile <lile@stdio.com> To: freebsd-net@freebsd.org Cc: Archie Cobbs <archie@whistle.com> Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <Pine.BSF.4.05.10004262233520.64956-100000@heathers.stdio.com> In-Reply-To: <Pine.BSF.4.05.10004262022520.64956-100000@heathers.stdio.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10004262233520.64956-100000>