Received: by 10.213.65.68 with SMTP id h4csp1548218imn; Thu, 29 Mar 2018 06:47:13 -0700 (PDT) X-Google-Smtp-Source: AIpwx489yhyGPfiIPAxuRsAgGh5AGilcq15/jUTolpLw8YMSLjuCJ/fe1Nxt3uECMHn9ckuEOeV4 X-Received: by 2002:a17:902:444:: with SMTP id 62-v6mr8620146ple.127.1522331233422; Thu, 29 Mar 2018 06:47:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522331233; cv=none; d=google.com; s=arc-20160816; b=L+XRukO4qsRuJPe5DLrtj0oGzSLdxxj+8LW9N9mADrOBFPZwDJBH5ur+a3FFi8XbB8 W1lsLyq3tNwaO77XKqmc81oQWCTTk3bJ30iYAfOSrWCKS2u7q37IvDFmqZ60lvocCnFR pA3Q/m4vaB6XyF5yMe0qjpwP0abiYXHQiDRhstvZ6aifxXNjwlPnL/Ayw5ngktrUZJGC qyOFjhRNKuRxksSNDLmQiovjRRS4fq54UX5/ch+214QjwItUczNu+q9TVagZFhxXwJc6 GVGtjn7mbbBbcuEie5PrZXKyG7aSmjhZ3cfnaL6/QvwWPW/QctoeJFWAkM4BMw9slPKY ToWA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=f3U0WThc+E3YCLwfRB+sWdZnOCcLtYTxHPhk2MbrLpc=; b=LloDh8TSIENmXP+0PA6GjmDJXFCiBsOOImdEuYvkCqPpDDB6Hhud3j9JH/UgVpfx9V xwK17R3KnGSxiLTOYeScxVhodlYkeoGnGz8KntXWGcfaWFffUTFU4GaYLIFhNc/6CgYf OsCJ1vGuSO0Fg0PlV5pp5nLTUMEBthdGf3aArjalhDADi46Ts/GWMYGltA7uG9rvA0TO RSRb7V4v/OU2jNb2SiI7S5FoiFXbnHmr6uMmi9eshspdFeyi6fWltGaxmxr02Bwe0u0h 2d75ceqlMgxeLdVOGPS9SG20EVJfquKiKOg2ljrcUBV/Oh7UR+x4yzKd+aWPA7+T3bQz p+yA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=Tpf7Elgu; dkim=pass header.i=@codeaurora.org header.s=default header.b=Tpf7Elgu; 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 r62si4638507pfe.68.2018.03.29.06.46.58; Thu, 29 Mar 2018 06:47:13 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=Tpf7Elgu; dkim=pass header.i=@codeaurora.org header.s=default header.b=Tpf7Elgu; 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 S1752805AbeC2Npn (ORCPT + 99 others); Thu, 29 Mar 2018 09:45:43 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:35432 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752067AbeC2Npl (ORCPT ); Thu, 29 Mar 2018 09:45:41 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 82F9A60C65; Thu, 29 Mar 2018 13:45:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522331140; bh=VMAEl3nM/bgazaXNjU2BjHppo2Vaa78+k5bcNFfkjU0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Tpf7ElguAD8Y8Jmnjmr17AoqkCw/+Fq1UwY4alwc0Iyxptx0DyLe+ZYodsfM7VZdj f4SnzOpnMh3T75LMIzI/fA1qKfuybHcRz/pfmdMbw2Ic8LXk1yjfdIl+U2bA1QdrDX 3c9Q1JQq1XNwmpcLsKksqPu+74DoSe5rGr09VXBg= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [192.168.0.105] (cpe-174-109-247-98.nc.res.rr.com [174.109.247.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 23DE560AFB; Thu, 29 Mar 2018 13:45:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1522331140; bh=VMAEl3nM/bgazaXNjU2BjHppo2Vaa78+k5bcNFfkjU0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Tpf7ElguAD8Y8Jmnjmr17AoqkCw/+Fq1UwY4alwc0Iyxptx0DyLe+ZYodsfM7VZdj f4SnzOpnMh3T75LMIzI/fA1qKfuybHcRz/pfmdMbw2Ic8LXk1yjfdIl+U2bA1QdrDX 3c9Q1JQq1XNwmpcLsKksqPu+74DoSe5rGr09VXBg= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 23DE560AFB Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH v7 3/7] bnx2x: Replace doorbell barrier() with wmb() To: "Elior, Ariel" , "netdev@vger.kernel.org" , "timur@codeaurora.org" , "sulrich@codeaurora.org" Cc: "linux-arm-msm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Dept-Eng Everest Linux L2 , "linux-kernel@vger.kernel.org" References: <1521988761-30344-1-git-send-email-okaya@codeaurora.org> <1521988761-30344-4-git-send-email-okaya@codeaurora.org> From: Sinan Kaya Message-ID: Date: Thu, 29 Mar 2018 09:45:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ariel, On 3/29/2018 5:17 AM, Elior, Ariel wrote: >> Subject: [PATCH v7 3/7] bnx2x: Replace doorbell barrier() with wmb() >> >> barrier() doesn't guarantee memory writes to be observed by the hardware on >> all architectures. barrier() only tells compiler not to move this code >> with respect to other read/writes. >> >> If memory write needs to be observed by the HW, wmb() is the right choice. > The wmb() is there (a couple of lines above). Your modification adds an > unnecessary fence which would hurt high pps scenarios. The memory > writes which the HW needs to observe are the buffer descriptors, not the > producer update message. The producer is written to the HW, and exists > on the stack. The barrier() is there to prevent the compiler from mixing the > order of the prod update message preparation and writing it to the host. > A possible alternative would be to move the existing wmb() to where > the barrier() is, achieving both goals, although in the existing design each > barrier has a distinct purpose. The comment location is misleading, though. I was told that barrier() is there to guarantee that HW is observing the memory write before writel(). I reacted to this and changed barrier() to wmb() following the old directions. You are saying that this not true. Since then, Linus gave us direction not to have wmb() in front of writel() as writel() already has memory-IO guarantee. https://www.mail-archive.com/netdev@vger.kernel.org/msg225806.html I'll be doing one more pass to remove wmb() before writel() soon. Please review that carefully. Intel drivers use wmb() as a substitute for smp_wmb(). So, we can't always assume that you can remove all wmb() in front of writel() as the write barrier seems to serve dual purpose. Please help me getting this right on the next version. Sinan -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.