Received: by 10.213.65.68 with SMTP id h4csp548163imn; Fri, 23 Mar 2018 10:06:20 -0700 (PDT) X-Google-Smtp-Source: AG47ELszUDFqDuvT+pQeY+iwCNbB813qZS9okISDXSWarPhOP7N8TOPvv5Fuq//g5z4iVUb4ZLBr X-Received: by 2002:a17:902:9009:: with SMTP id a9-v6mr29521809plp.272.1521824780771; Fri, 23 Mar 2018 10:06:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521824780; cv=none; d=google.com; s=arc-20160816; b=a8P4exWpipnceWIw5xhXi9cMTTQUTQqniH8AI5VgsbjRehzs0Uj5+ildCZfq7Y6V5H /tJduSLUgWXbvQlg/B41OzHj+J3YjRDPgeJ1se8qOXzUxsWcCfwQGbbwPtzpXGbA42fn LlRDkjCWKvjlep8kGmZZsnXJC9FYZIbO8rzoNdQgVUJFkCm19o01ANmG3Lk7Z8gITomy mKILy8KFbh4gdhvhXjhXF/9jx8SsjlPuWeAm4tXnwlEBLUFW+31Xc1kL1saSHYXEf00N 2xGMVLbrr1/7+gDUHc3y2HIIAP5l01H91g0g77ZPkyZmoiw0ibgM71J95lGK6cJNaXh+ PA4w== 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=+CL3OQW2kAIDVxUnaQX7kASMd4S+we8BBhBBDiTrsP0=; b=YjiajDWZYii1uIOzY3ok0qLb3JiBAvHn+I326uzlWu+kzomjfAlUTIxT/KxO2n+ktK se35Q8ASbqfLq/wRKXM8ktWd71VjkghJxMm6CWlJD75BVGSqlHWBX77SbOON+GBCJztR zt1ijCRKi/EsNPystB2clzIpkvR5hohajBvspMSq61opoXApcgiNNSJqawLkJe8jb0h4 3fbmEe31dyuC4yjEzxBlaxQ2X9zaNIu7WzGcWwbQNzjladlHMIZ1yoL2F0X46OeqP1Er M0GzYX4lRq1OSGUwyg35IJRnGvbN4dV+GUcliTraalv8vEsbSoqyVDSHllU/g6XuOkRg mSHQ== 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 e1si6857453pfn.243.2018.03.23.10.05.51; Fri, 23 Mar 2018 10:06:20 -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 S1752237AbeCWREV (ORCPT + 99 others); Fri, 23 Mar 2018 13:04:21 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:43962 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751427AbeCWREU (ORCPT ); Fri, 23 Mar 2018 13:04:20 -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 14047145C6E84; Fri, 23 Mar 2018 10:04:19 -0700 (PDT) Date: Fri, 23 Mar 2018 13:04:18 -0400 (EDT) Message-Id: <20180323.130418.2223623186761161723.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: <4bd9ccd2-df8f-acad-2513-eefe065dc852@codeaurora.org> References: <20180323.124326.2170503491903886041.davem@davemloft.net> <4bd9ccd2-df8f-acad-2513-eefe065dc852@codeaurora.org> 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 10:04:19 -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:51:47 -0400 > It could if txdata->tx_db was not a union. There is a data dependency > between txdata->tx_db.data.prod and txdata->tx_db.raw. > > So, no reordering. I don't see it that way, the code requires that: txdata->tx_db.data.prod += nbd; is visible before the doorbell update. barrier() doesn't provide that. Neither does writel_relaxed(). However plain writel() does. Therefore the code is only correct as-is, and your change potentially adds a reordering problem.