Date: Wed, 26 Apr 2000 01:11:34 -0500 From: "C. Stephen Gunn" <csg@waterspout.com> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-net@FreeBSD.ORG, luigi@FreeBSD.ORG, remy@boostworks.com, pavel@alum.mit.edu, nsayer@sftw.com, juliam@elischer.org Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <20000426011134.A768@waterspout.com> In-Reply-To: <200004260003.RAA55104@bubba.whistle.com>; from archie@whistle.com on Tue, Apr 25, 2000 at 05:03:57PM -0700 References: <20000425164027.A2553@waterspout.com> <200004260003.RAA55104@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 25, 2000 at 05:03:57PM -0700, Archie Cobbs wrote: > Well, the mbuf is aligned.. so if the IP header starts at mbuf + > 14, then it's not aligned... and m_adj() won't help either.. but > I don't know whether this is still valid though. However, a couple > of drivers take pains to handle this. You're Correct I discussed this with Bill Paul on IRC just to make sure that I wasn't insane. Several drivers go through horrible pain to make sure that the mbuf chain is 32-bit word aligned _after_ the removal of the Ethernet header. Like Garrett said, apparently some Ethernet hardware (the "better" cards mind you) can DMA to any address, others can only do it on 16-bit or 32-bit boundaries, hence the flaming hoops. Whatever the case, it should be fair to assume that an mbuf coming into ether_input() should be aligned correctly. A deferral of the m_adj() call shouldn't hurt anything, and cleans up a lot. > See dev/ie/if_ie.c for an example.. From reading the code, the driver doesn't have to operate this way. It just allocates an ether_header seperate from the mbuf chain. This data could be in the mbuf (with some alignment haggling) with very little drop in performance. I'd be happy to author/test/contrib these changes, but I need to get by hands on an if_ie card. I've put out some feelers to see if I can find/borrow one. Looks like the other culprits are: sys/dev/ie/if_ie.c sys/i386/isa/if_el.c sys/i386/isa/if_le.c sys/i386/isa/if_wl.c As far as I can tell, these are all old ISA cards. So the performace hit on a modern machine can't be that bad. Someone is taking a performance hit. I'd vote that it shouldn't be high-end configurations like Gigabit + VLANs, or anybody with a BPF open (think about DHCP). Don't get me wrong here, I'm not saying we should do anything to break support for older hardware, simply to optimize for the the average Ethernet hardware available today. > - If the 'eh' parameter to ether_input() is NULL, then don't > do any of the link-layer stuff. This allows the existing > optimization in the if_ed.c driver to work the same. As Julian pointed out, this won't work since we need the the ether_type inside ether_input(). This is certainly available if it hasn't been trimmed from the mbuf chain yet. (See above) Luigi -- Could you please remark about the optimizations in if_ed.c? I want to fully udnerstand your motivations. Is it simply due to having the ed device in promisc mode for bridging, and trying to optimize the "we don't need to forward this packet" case? - Steve 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?20000426011134.A768>