From owner-svn-src-user@FreeBSD.ORG  Sat Nov  8 16:53:56 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 277F5106567C;
	Sat,  8 Nov 2008 16:53:56 +0000 (UTC)
	(envelope-from asmrookie@gmail.com)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152])
	by mx1.freebsd.org (Postfix) with ESMTP id 28B728FC16;
	Sat,  8 Nov 2008 16:53:54 +0000 (UTC)
	(envelope-from asmrookie@gmail.com)
Received: by fg-out-1718.google.com with SMTP id l26so1479615fgb.35
	for <multiple recipients>; Sat, 08 Nov 2008 08:53:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:sender
	:to:subject:in-reply-to:mime-version:content-type
	:content-transfer-encoding:content-disposition:references
	:x-google-sender-auth;
	bh=026roWEMMFdDDGLPKrZix30bWgqP8kAXrx9tobGTFFg=;
	b=xAEQMkF6bhfuOtwarVxwyVTD/l7T1m2pWp6BNjR3SQPSt9VKuOOt5XJlJ60B34Q6Ae
	Rm+M21kIVRkayj8gUfyq0QvFvQcLjZII9x5KsBlIMJdVwU0+Is+V3cCNJTqtvFTBgvuY
	qkQGYDpFGj85Rb3854LpBzqw1NcrIA39rfSAY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references:x-google-sender-auth;
	b=mcdrOQzMnKSRq0woptn4bOoMHWF6nZUTZcNRZf39FI+J4GyL7SG2L5JKgZcdXaliTH
	jm/SlhB+Sx9xQeg0vgSwHxnK1H1cGWSwbXLaA6OYJaA/m4yWKo4KUJXkY6bMXESjPic4
	2rdBPjyH7lABMl62KFrpgSx5Fh/qVR0L9c780=
Received: by 10.86.4.14 with SMTP id 14mr5256750fgd.27.1226163233975;
	Sat, 08 Nov 2008 08:53:53 -0800 (PST)
Received: by 10.86.2.18 with HTTP; Sat, 8 Nov 2008 08:53:53 -0800 (PST)
Message-ID: <3bbf2fe10811080853j3ebf5b2em29ebdd2a7187ff67@mail.gmail.com>
Date: Sat, 8 Nov 2008 17:53:53 +0100
From: "Attilio Rao" <attilio@freebsd.org>
Sender: asmrookie@gmail.com
To: "Attilio Rao" <attilio@freebsd.org>, "Kip Macy" <kmacy@freebsd.org>, 
	src-committers@freebsd.org, svn-src-user@freebsd.org
In-Reply-To: <20081108163006.GA5256@zim.MIT.EDU>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <200811080202.mA822D0W098283@svn.freebsd.org>
	<3bbf2fe10811080530t6846fce8mdf62f755c1864ea2@mail.gmail.com>
	<20081108163006.GA5256@zim.MIT.EDU>
X-Google-Sender-Auth: 397ef25b889c4b12
Cc: 
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:53:56 -0000

2008/11/8, David Schultz <das@freebsd.org>:
> 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.

But this is an atomic op too.

>  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.

_acq prefix is intended to not let reordering happening really.
man 9 atomic can explain how the acq and rel memory barriers work.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein