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

[ Available lists | Index of cvs-src | Month of Jul 2005 | Week of 5 Jul 2005 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Peter Wemm <peter@wemm.org>
Date
5 Jul 2005 17:53:38
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


[ Hide this part ]
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


Elapsed time: 0.214 seconds