From owner-svn-src-user@FreeBSD.ORG  Sat Nov  8 16:50:35 2008
Return-Path: <owner-svn-src-user@FreeBSD.ORG>
Delivered-To: svn-src-user@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 61FC81065676;
	Sat,  8 Nov 2008 16:50:35 +0000 (UTC) (envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101])
	by mx1.freebsd.org (Postfix) with ESMTP id 1B8FF8FC23;
	Sat,  8 Nov 2008 16:50:34 +0000 (UTC) (envelope-from das@FreeBSD.ORG)
Received: from zim.MIT.EDU (localhost [127.0.0.1])
	by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id mA8GU62B005341;
	Sat, 8 Nov 2008 11:30:06 -0500 (EST) (envelope-from das@FreeBSD.ORG)
Received: (from das@localhost)
	by zim.MIT.EDU (8.14.3/8.14.2/Submit) id mA8GU6VX005340;
	Sat, 8 Nov 2008 11:30:06 -0500 (EST) (envelope-from das@FreeBSD.ORG)
Date: Sat, 8 Nov 2008 11:30:06 -0500
From: David Schultz <das@FreeBSD.ORG>
To: Attilio Rao <attilio@FreeBSD.ORG>
Message-ID: <20081108163006.GA5256@zim.MIT.EDU>
Mail-Followup-To: Attilio Rao <attilio@FreeBSD.ORG>,
	Kip Macy <kmacy@FreeBSD.ORG>, src-committers@FreeBSD.ORG,
	svn-src-user@FreeBSD.ORG
References: <200811080202.mA822D0W098283@svn.freebsd.org>
	<3bbf2fe10811080530t6846fce8mdf62f755c1864ea2@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3bbf2fe10811080530t6846fce8mdf62f755c1864ea2@mail.gmail.com>
Cc: src-committers@FreeBSD.ORG, Kip Macy <kmacy@FreeBSD.ORG>,
	svn-src-user@FreeBSD.ORG
Subject: Re: svn commit: r184759 - user/kmacy/HEAD_fast_multi_xmit/sys/net
X-BeenThere: svn-src-user@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SVN commit messages for the experimental &quot; user&quot;
	src tree" <svn-src-user.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-user>,
	<mailto:svn-src-user-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-user>
List-Post: <mailto:svn-src-user@freebsd.org>
List-Help: <mailto:svn-src-user-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-user>,
	<mailto:svn-src-user-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Nov 2008 16:50:35 -0000

On Sat, Nov 08, 2008, Attilio Rao wrote:
> Definitively, I'm not sure we need this.
> We alredy have memory barriers you could exploit which just require a
> "dummy" object.
> 
> For example you could do:
> flowtable_pcpu_unlock(struct flowtable *table, uint32_t hash)
>  {
> 
>         (void)atomic_load_acq_ptr(&dummy);
>         ...

Memory barriers are cheaper than atomic ops.

Furthermore, there's different types of memory barriers
(store/store, load/store, etc.), not just a generic mb().  Some
architectures like sparc64 define all four, but only actually
implement the varieties that are useful in improving performance.
Take a look at what Solaris has here.

I'm skeptical of trying to play clever tricks with these things
outside of the code that implements synchronization
primitives. Memory ordering is very hard to reason about, and we
already have a lot of code, e.g., in libthr, that isn't correct
under weak memory ordering. Moreover, the compiler can reorder
loads and stores, and that just adds a whole new level of pain.