From owner-cvs-all@FreeBSD.ORG  Mon Jul  4 10:12:56 2005
Return-Path: <owner-cvs-all@FreeBSD.ORG>
X-Original-To: cvs-all@freebsd.org
Delivered-To: cvs-all@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7B92B16A437;
	Mon,  4 Jul 2005 10:12:56 +0000 (GMT)
	(envelope-from phk@phk.freebsd.dk)
Received: from haven.freebsd.dk (haven.freebsd.dk [130.225.244.222])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 2ED2443D49;
	Mon,  4 Jul 2005 10:12:56 +0000 (GMT)
	(envelope-from phk@phk.freebsd.dk)
Received: from phk.freebsd.dk (unknown [192.168.48.2])
	by haven.freebsd.dk (Postfix) with ESMTP id 425BBBC50;
	Mon,  4 Jul 2005 10:12:54 +0000 (UTC)
To: Peter Grehan <grehan@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
In-Reply-To: Your message of "Mon, 04 Jul 2005 20:06:33 +1000."
	<42C90A29.2030706@freebsd.org> 
Date: Mon, 04 Jul 2005 12:12:53 +0200
Message-ID: <29301.1120471973@phk.freebsd.dk>
Sender: phk@phk.freebsd.dk
Cc: cvs-src@freebsd.org, src-committers@freebsd.org,
	Robert Watson <rwatson@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 
X-BeenThere: cvs-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the entire tree <cvs-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-all>
List-Post: <mailto:cvs-all@freebsd.org>
List-Help: <mailto:cvs-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-all>,
	<mailto:cvs-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2005 10:12:57 -0000

In message <42C90A29.2030706@freebsd.org>, Peter Grehan writes:
>>> 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. 
>> 
>> While it's not immediately relevant to the IP code, generally speaking, 
>> is it the case that non-aligned integer reads can be non-atomic with 
>> respect to other CPUs due to the multiple access implementation?
>
>  I'd say certainly ! In fact, are there any architectures that could 
>guarantee atomicity in this case ?

Yes, the alphas "load/store conditional" could, provided that the
field is entirely inside a cache-line.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.