From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by dpdk.org (Postfix) with ESMTP id EC5571075 for ; Wed, 22 Mar 2017 01:14:09 +0100 (CET) Received: by mail-qk0-f173.google.com with SMTP id p64so147659899qke.1 for ; Tue, 21 Mar 2017 17:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atomicrules-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dkAMT5RM5VXwrFyY+u0LnrKAeGStk8dl1DgCElNqjmM=; b=HqI08HTo2lrndAmP2slk8khUQuAddgiA7o9WkXJ6qyypO4S0iyxqT1H0VDmYol+slM V8KCKfeWrgbDt/SDBrbm1JjdG6/rvtImPFfmbr2JQ0etVSZ+4rSHFEa+kDz3W1MJ8ZER 1cfV4JX7/u9uSrrqCNVRtc/Fe2W76g3cEbQTGReR09AobqD9Z1Pj1mosStLjOfrK1cue 6GHsKYivm5iJHYWstwQ3GXixYcEBikMLsIMnLuKQRNVayaZ1alwhPFGclmUtKY9Vq5al WdxXD8PVy3EQSCiwsOdBO8vuunIqa8AqISsPtrtYtV5G0tKrxMMqc7NE8pB2eOp4POCX /cMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dkAMT5RM5VXwrFyY+u0LnrKAeGStk8dl1DgCElNqjmM=; b=AQWlQSzo1PNYFCzcpDsHxi0k387q2NREMczY8c60Kqn87Kpa4x2txB7BwZP8C5THFw wlfTBofUcB2t1oQsuySsXsN7QIb0FNFBlYbICULYPI2uSEvk3ogB5wqpvJmJfmCU+QfY QI4ONH7DsJM9o2uh8EEibfoJctFhdi0vgcf+JhDdbn+JMMxU7Xu8nNIFWsQRJ2xyvk0H 2aJ/PvEenfluvgBUWY9Rg5cA4d8E2z5D2DN2qHvpFZ9YQoMFn0VGdCXtNaaE4L0vJwsi 86sTfUSfIVyB4qceB1VpAbxAeD5qWHngsgqlBcymT5UnWbsboxlrC5BQdikX7n7D2QLm HfAw== X-Gm-Message-State: AFeK/H3XcwtHji5Rd4oX7vKXFO/6I+vFbmfnGHbQdn7EO7D4kWBaAgZBmzX6xCT4lSeUBaSLhTXbtw2kcpFpJQ== X-Received: by 10.55.151.3 with SMTP id z3mr12979891qkd.79.1490141649178; Tue, 21 Mar 2017 17:14:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.1.131 with HTTP; Tue, 21 Mar 2017 17:13:48 -0700 (PDT) In-Reply-To: <20170321151552.2d172477@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> From: Ed Czeck Date: Tue, 21 Mar 2017 20:13:48 -0400 Message-ID: To: Stephen Hemminger Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:14:10 -0000 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.