From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v3 2/7] net/ark: HW API part 1 of 3 Date: Tue, 21 Mar 2017 17:30:29 -0700 Message-ID: <20170321173029.15af2a76@xeon-e3> References: <1490132621-7851-1-git-send-email-ed.czeck@atomicrules.com> <1490132621-7851-2-git-send-email-ed.czeck@atomicrules.com> <20170321151552.2d172477@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Ed Czeck Return-path: Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com [209.85.192.170]) by dpdk.org (Postfix) with ESMTP id E6A8A11C5 for ; Wed, 22 Mar 2017 01:30:37 +0100 (CET) Received: by mail-pf0-f170.google.com with SMTP id 20so38507501pfk.2 for ; Tue, 21 Mar 2017 17:30:37 -0700 (PDT) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 21 Mar 2017 20:13:48 -0400 Ed Czeck wrote: > Hi Stephen, > > Yes I understand the paranoid issue of volatile modifier, which is the > reason it was coded in this manner. > > The struct with volatile are memory mapped IO structures. These structure > are not instantiated in memory and hence do not incur concurrent (host) > software access. The a vast majority of the fields as read-only (as viewed > by the host.) The concurrency model is that hardware is the producer, and > the host the consumer. There is no handshake other than the host must not > expect the memory location to remain constant -- that is optimization off. > > As for performance, these structures are not in any critical path, so he > optimization path is correctness not performance. > > Do you have a recommendation for changing this code without using the > volatile modifier? I have requirements from the hardware in the pattern of: > write a 1 to location x > read from location y until it become 0 > write a 0 to location x > How can this work without a volatile modified on x and y? > > Best, > Ed. Learn to use explicit memory barriers. DPDK has rmb()/wmb() just like kernel. Once again good explanation of memory barriers in kernel doc.