Date: Tue, 5 Jul 2005 10:53:36 -0700 From: Peter Wemm <peter@wemm.org> To: Peter Grehan <grehan@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Andrew Thompson <thompsa@freebsd.org> Subject: Re: cvs commit: src/sys/amd64/include _types.h src/sys/i386/include _types.h src/sys/net if_bridge.c src/sys/netinet ip_var.h src/sys/netinet6 ip6_var.h Message-ID: <200507051053.37195.peter@wemm.org> In-Reply-To: <42C90419.8070509@freebsd.org> References: <200507022313.j62NDWYC028248@repoman.freebsd.org> <42C90419.8070509@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 04 July 2005 02:40 am, Peter Grehan wrote: > > Check the alignment of the IP header before passing the packet up > > to the packet filter. This would cause a panic on architectures > > that require strict alignment such as sparc64 (tier1) and ia64/ppc > > (tier2). > > FYI, any modern ppc implementation doesn't require strict alignment > for integer load/stores though there's a performance penalty for > having to split the access into smaller ones. As an aside, I've been contemplating taking a shot at having the AC (alignment checking) turned on for the amd64 kernel and see what breaks. But rather than trying to do bit-shifting bcopys etc, I was thinking about toggling it off/on around known offenders. It could be interesting to allow userland to turn it on/off for its own use as well. But I suspect that touching %cr0 on the fly at syscall entry/exit could be a serious microcode cost. But still, it might be an interesting thing to have available as a diagnostic tool. Unaligned accesses are slower here too. And there are ugly side effects if the unaligned access crosses a cache line boundary. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507051053.37195.peter>