From patchwork Mon Mar 13 17:00:03 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Gunthorpe X-Patchwork-Id: 9621697 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9744560492 for ; Mon, 13 Mar 2017 17:38:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8956F2848F for ; Mon, 13 Mar 2017 17:38:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 7E33C284D8; Mon, 13 Mar 2017 17:38:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0968C2848F for ; Mon, 13 Mar 2017 17:38:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754465AbdCMRiG (ORCPT ); Mon, 13 Mar 2017 13:38:06 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:43094 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754377AbdCMRiG (ORCPT ); Mon, 13 Mar 2017 13:38:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=obsidianresearch.com; s=rsa1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=7XbbSnV4Cdx/LnKrEfSufqPSiHOqXvk4D1TuQc4Sv3o=; b=JPyedNaOHb69WC0j7R7Rv+qN7PVjdK3dYUbw0Zr0ack5w4GhwzlFiLgWpX0z8WJZ05JFGKl2vEPT440p/Jm1QWdgoRZz+9TlyG0lfsvohaBFYGR73IimXlNYtqDIgvrpsZIXU6fVWJhXBiUKjMPYCsGF7IBQXe3ejDwkQ/mmLDc=; Received: from [10.0.0.156] (helo=jggl.edm.orcorp.ca) by quartz.orcorp.ca with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cnTKF-0006y0-S6; Mon, 13 Mar 2017 11:00:03 -0600 Received: from jgg by jggl.edm.orcorp.ca with local (Exim 4.86_2) (envelope-from ) id 1cnTKF-0006zK-Pw; Mon, 13 Mar 2017 11:00:03 -0600 Date: Mon, 13 Mar 2017 11:00:03 -0600 From: Jason Gunthorpe To: Yishai Hadas Cc: dledford@redhat.com, linux-rdma@vger.kernel.org, majd@mellanox.com Subject: Re: [PATCH rdma-core 1/3] verbs: Add mmio_wc_spinlock barrier Message-ID: <20170313170003.GC25664@obsidianresearch.com> References: <1489416829-15467-1-git-send-email-yishaih@mellanox.com> <1489416829-15467-2-git-send-email-yishaih@mellanox.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1489416829-15467-2-git-send-email-yishaih@mellanox.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Mar 13, 2017 at 04:53:47PM +0200, Yishai Hadas wrote: > From: Jason Gunthorpe > > For x86 the serialization within the spin lock is enough to > strongly order WC and other memory types. > > Add a new barrier named 'mmio_wc_spinlock' to optimize > that. Please use this patch with the commentary instead: --- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/util/udma_barrier.h b/util/udma_barrier.h index 9e73148af8d5b6..cfe0459d7f6fff 100644 --- a/util/udma_barrier.h +++ b/util/udma_barrier.h @@ -33,6 +33,8 @@ #ifndef __UTIL_UDMA_BARRIER_H #define __UTIL_UDMA_BARRIER_H +#include + /* Barriers for DMA. These barriers are expliclty only for use with user DMA operations. If you @@ -222,4 +224,37 @@ */ #define mmio_ordered_writes_hack() mmio_flush_writes() +/* Write Combining Spinlock primitive + + Any access to a multi-value WC region must ensure that multiple cpus do not + write to the same values concurrently, these macros make that + straightforward and efficient if the choosen exclusion is a spinlock. + + The spinlock guarantees that the WC writes issued within the critical + section are made visible as TLP to the device. The TLP must be seen by the + device strictly in the order that the spinlocks are acquired, and combining + WC writes between different sections is not permitted. + + Use of these macros allow the fencing inside the spinlock to be combined + with the fencing required for DMA. + */ +static inline void mmio_wc_spinlock(pthread_spinlock_t *lock) +{ + pthread_spin_lock(lock); +#if !defined(__i386__) && !defined(__x86_64__) + /* For x86 the serialization within the spin lock is enough to + * strongly order WC and other memory types. */ + mmio_wc_start(); +#endif +} + +static inline void mmio_wc_spinunlock(pthread_spinlock_t *lock) +{ + /* It is possible that on x86 the atomic in the lock is strong enough + * to force-flush the WC buffers quickly, and this SFENCE can be + * omitted too. */ + mmio_flush_writes(); + pthread_spin_unlock(lock); +} + #endif