Received: by 10.213.65.68 with SMTP id h4csp532407imn; Fri, 23 Mar 2018 09:46:46 -0700 (PDT) X-Google-Smtp-Source: AG47ELvpo5KGLZpySCwgNgvfsIB5faARl1GRy4vq6S5GqnaZQsqsPUsQDNlqBif/TOpXrTrUOw2v X-Received: by 2002:a17:902:ab81:: with SMTP id f1-v6mr25650313plr.5.1521823606596; Fri, 23 Mar 2018 09:46:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521823606; cv=none; d=google.com; s=arc-20160816; b=CB/5f5l83aE2gAXxdsclh87lOAEFYeQPQjROl7geXeyu8nMpIfRp1KkYjz/iuhr66m naxthc4oXqJkkdsNLJ10/A4EouT+PReHeW0QgA97MRXs8MRyb0DLRZTxlArcWe0Dl8LJ zrUC2pm1lWqnbhKLcZIgF9yvzT/nxn8+GoBDc0NQRWn38BdXvMSTc1C51eei5jrgNlw6 tLhwIzMhko+ylZWgRVKsHffhwG5KUwk5UG5JbycBWE2uoTnEKychfiPy6N2MdQtf60Wl uD6UfZpYNpOsPTkQTailM6R0AXj+YqVwOuxYt57EMb9Ff4Yxo3EZmaYX4JVIXF0maZQD xpmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=GAB15upJrAys5dWkPAIx253eQR9rB/Toh+xiTg4Z4+Q=; b=hJOgxmdSOOS2Mv+axgD8JfZOztueg5+Qe3q9Bo+ZMyjY4fLATaafi2dCiRKO8HXxnc SjWGjq5gunyAN1n31ZZwtuq8MqoVxCAaxLknSaYnTdRPzzKVDSavqn27cSZ6PPy4al9v cghR5XqKd4CMwTJiAOnrc7TX56roWRzzFc970eyZ0WOylCAKriS7fQcjg3MC3695qVGH DwiKRPkNcFIklWOThJ8KIcWUCKHn4YIpAJCG3yv7v+s9YU437QnTH2HeHSsKGvnmvspW BYntNVPaT/mnHKG+qwNMsSGYVT5uiAcTJEIXx+SPY3fD1pKuspVNPr72cHbHVwLiai4x O16Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 61-v6si2548464plz.630.2018.03.23.09.46.01; Fri, 23 Mar 2018 09:46:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752203AbeCWQna (ORCPT + 99 others); Fri, 23 Mar 2018 12:43:30 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:43692 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbeCWQn2 (ORCPT ); Fri, 23 Mar 2018 12:43:28 -0400 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 9572D145C6E80; Fri, 23 Mar 2018 09:43:27 -0700 (PDT) Date: Fri, 23 Mar 2018 12:43:26 -0400 (EDT) Message-Id: <20180323.124326.2170503491903886041.davem@davemloft.net> To: okaya@codeaurora.org Cc: netdev@vger.kernel.org, timur@codeaurora.org, sulrich@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, ariel.elior@cavium.com, everest-linux-l2@cavium.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 3/5] bnx2x: Eliminate duplicate barriers on weakly-ordered archs From: David Miller In-Reply-To: References: <1521738603-23596-4-git-send-email-okaya@codeaurora.org> <20180323.122035.1380806748695640531.davem@davemloft.net> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 23 Mar 2018 09:43:28 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sinan Kaya Date: Fri, 23 Mar 2018 12:31:12 -0400 > Sorry, you got me confused now. > > If you look at the code closer, you'll see this. > > wmb(); > > txdata->tx_db.data.prod += nbd; > barrier(); > > DOORBELL(bp, txdata->cid, txdata->tx_db.raw); > > and you also asked me to rename DOORBELL to DOORBELL_RELAXED() to make > it obvious that we have a relaxed operator inside the macro. This still doesn't match the stated pattern. wmb(); /* no other memory or I/O or IOMEM operation */ writel(); There is a write to a producer index there and then no non-compiler barrier or any kind before the writel(). So, in fact, it might really need that implicit writel() barrier here!