From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=oRxb0dYPQX8dArp+KoKgkzEF9VXKBCiq/rVD/8Am4AE=; b=z7cX6SQLOygawbWCmcDXHNYSlkFob1uPSg5E3Q1FGyR2TvNe07/nPoini/OPlAH3q4 1kR8JXrlE+L+B9LTBse9up1WTc4uRX10eKvHgGV2TyhlbcOWPz1JkXDmQrcjwesgQeaJ yS7U3LXbleG0FLTnPwRl9lYjBiSYq0cGC3ei7sq+wizm5cUiw3mM8UiMqCJUvjhzAU2C TcYaur6pn1MlB/QpkTbeJCH2FZgPcm1BJ6h4yKSMxhJkUQTBnCtacDsLknRKfAX7Bjzc cC+bWEgjPgONYvWKogfd1OgNLntlbCQ7kaZIsjdarg0A5iOYpCSuPDVqq2Nca4CT6zH9 pMFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=oRxb0dYPQX8dArp+KoKgkzEF9VXKBCiq/rVD/8Am4AE=; b=Oqin+uZmPjg/e2sRHo2NtoKVi0UfQprFUwT6ALImkrIT6QXyWejsXbTYFgp26TZ65r pUaUIUxwIaKtJujOMJ3c8/G+4ZdivWo5cwTquDcwQY9zvn9y7XBq+fKNnv1PvllFGMbz c7E07LQHg5TdlilXs+LR0v+h3BhaTYO1Mrn6tBHFKQwKuZ2lGK3lTb9CSN/z155RF0Ue OV7WhrOq6x3QWKCZWkk0FuresDbgKr5tRlgMiv8omNIRr8gVCnfP2yXRHZey/ncPWdbS 4IsaN0dt0YTbqyMycQZ5OzadbnxwC++T8rO0F+MdniOKyvPDkjWojHFclNK08bfAgNJj x9Ug== X-Gm-Message-State: AFeK/H1m+H01hD0Fn5cUccjIWMo78s+hm9c8YwTdWNKzC4HOA3iCGNSzqAIr4oF0lEymJw== X-Received: by 10.84.160.195 with SMTP id v3mr51333230plg.161.1490142636945; Tue, 21 Mar 2017 17:30:36 -0700 (PDT) Received: from xeon-e3 (204-195-18-65.wavecable.com. [204.195.18.65]) by smtp.gmail.com with ESMTPSA id r13sm41727421pfg.55.2017.03.21.17.30.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 21 Mar 2017 17:30:36 -0700 (PDT) Date: Tue, 21 Mar 2017 17:30:29 -0700 From: Stephen Hemminger To: Ed Czeck Cc: dev@dpdk.org Message-ID: <20170321173029.15af2a76@xeon-e3> In-Reply-To: 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 Subject: Re: [dpdk-dev] [PATCH v3 2/7] net/ark: HW API part 1 of 3 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 00:30:38 -0000 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.