Received: by 10.213.65.68 with SMTP id h4csp1293483imn; Wed, 14 Mar 2018 15:58:55 -0700 (PDT) X-Google-Smtp-Source: AG47ELsuMrKKK4/aKGqQQB7EapWFyJl/ZhDpp3WKsmJA7B+T6vsdrDi3C3WIAqYbMWxbQkdo8cui X-Received: by 2002:a17:902:6f17:: with SMTP id w23-v6mr5770192plk.336.1521068335814; Wed, 14 Mar 2018 15:58:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521068335; cv=none; d=google.com; s=arc-20160816; b=i/zfY6o4kXn/188VaXz8IWYSW//EiGvVcxd4T+yKoJFGkYtrivk4C5bGPAbOHWxR2A ih0xc+vJjOJrFNRXX1wK2vDn4b3LPkkgh8neooMKJU8eaJjYD/92C9uECHt2jmcPBCpK E3qS9o3l9HwTrtcQSjasglSA9sklVMQlNfqquO1PODdk+do1cXs+HPKXoWC+W7CvgQ2w ViF4x3CJ2zwfAf9+HrZGJyYiss365QyG+1ej9lSc6xNvEqLWIFZv4RCtB9AWxKgHJp5g FwuOi781ykYJUNC59W/bRtL+jTo9AoVZIBdEzDrmTqG6XhMUjLjyK5y/gWb9czdP60f9 4RWg== 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=Jdlu2zSTc1r+F+vOySAi1TlL5fbqGV001zkCyBZDpJA=; b=C4Yg74b3JSIweaA4gAzvnRhNizdW7+/hmdcV/0NWcdTObSUF5ADs+zwL765FbD8JGj +lQNTWrhGbNEFhl9nKDzm0+QYZhCbOSqjYhtBeq6kZtj7hWdIyAh8vIhP1FGk6/erwwZ xV71bG1JDOw7ISbCtYIkxXwjF9d3sNrAu7WTOnmKX3e6lLus1K3/rXjrohk4yYLNFLiQ /LaGh5hRPh/IarPeq5EoyRFl4YRxtLzitxRiNOyMFWNLZhQGNtoQtKhLR02noL8ZbJCH YC6SaPzPGSozhCFPxHN60LBxdUuuALk6vF2Hrak6DS4NdSvBJMd9a6NCO9G9etoKkZRX 9pAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=M9teD+Vd; dkim=pass header.i=@codeaurora.org header.s=default header.b=M9teD+Vd; 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 60-v6si2682041plc.66.2018.03.14.15.58.41; Wed, 14 Mar 2018 15:58:55 -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=M9teD+Vd; dkim=pass header.i=@codeaurora.org header.s=default header.b=M9teD+Vd; 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 S1751595AbeCNW5q (ORCPT + 99 others); Wed, 14 Mar 2018 18:57:46 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:35896 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbeCNW5o (ORCPT ); Wed, 14 Mar 2018 18:57:44 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id CDA8160314; Wed, 14 Mar 2018 22:57:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521068263; bh=KBrK3HFWIokOt4TS4wHHZLiWrlvgGM180EZ/Zp0A/BE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M9teD+VdC5mr7SFdLfWY4tka1MxhhHXX7tb3iSqSgx7H/LoBW607eYd+Gymjto3qW NVd1xPaq9M69hd47OePFA6t8AjDziQ7KB98OlBHWAUb6KgFgrSNtbqw074QeV5I30M rA9cihjuqglSOynhNYkS+wAAEKIr0un+sFDTK1GY= 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 D650660314; Wed, 14 Mar 2018 22:57:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521068263; bh=KBrK3HFWIokOt4TS4wHHZLiWrlvgGM180EZ/Zp0A/BE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M9teD+VdC5mr7SFdLfWY4tka1MxhhHXX7tb3iSqSgx7H/LoBW607eYd+Gymjto3qW NVd1xPaq9M69hd47OePFA6t8AjDziQ7KB98OlBHWAUb6KgFgrSNtbqw074QeV5I30M rA9cihjuqglSOynhNYkS+wAAEKIr0un+sFDTK1GY= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org D650660314 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 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs To: Alexander Duyck Cc: Timur Tabi , Netdev , sulrich@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jeff Kirsher , intel-wired-lan , LKML References: <1520997629-17361-1-git-send-email-okaya@codeaurora.org> <1520997629-17361-7-git-send-email-okaya@codeaurora.org> <12150aa0-77ba-878e-31f4-d4f8d6a28ccb@codeaurora.org> <2a4f4dec64b7462ae64152f6c2df9754@codeaurora.org> From: Sinan Kaya Message-ID: Date: Wed, 14 Mar 2018 18:57:40 -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 Alexander, On 3/14/2018 5:49 PM, Alexander Duyck wrote: > On Wed, Mar 14, 2018 at 5:13 AM, wrote: >> On 2018-03-14 01:08, Timur Tabi wrote: >>> >>> On 3/13/18 10:20 PM, Sinan Kaya wrote: > Actually I would argue this whole patch set is pointless. For starters > why is it we are only updating the Intel Ethernet drivers here? I did a regex search for wmb() followed by writel() in each drivers directory. I scrubbed the ones I care about and posted this series. Note also that I have one Infiniband patch in the series. I considered "ease of change", "popular usage" and "performance critical path" as the determining criteria for my filtering. > This > seems like something that is going to impact the whole kernel tree > since many of us have been writing drivers for some time assuming x86 > style behavior. That's true. We used relaxed API heavily on ARM for a long time but it did not exist on other architectures. For this reason, relaxed architectures have been paying double penalty in order to use the common drivers. Now that relaxed API is present on all architectures, we can go and scrub all drivers to see what needs to change and what can remain. > > It doesn't make sense to be optimizing the drivers for one subset of > architectures. The scope of the work needed to update the drivers for > this would be ridiculous. Also I don't see how this could be expected > to work on any other architecture when we pretty much need to have a > wmb() before calling the writel on x86 to deal with accesses between > coherent and non-coherent memory. It seems to me more like somebody > added what they considered to be an optimization somewhere that is a > workaround for a poorly written driver. Either that or the barrier is > serving a different purpose then the one we were using. Is there a semantic problem with the definition of wmb() vs. writel() vs. writel_relaxed()? I thought everything is well described in barriers document about what to expect from these APIs. AFAIK, writel() is equal to writel_relaxed() on x86 architecture. It doesn't really change anything for x86 but it saves barriers on other architectures. > > It would make more sense to put in the effort making writel and > writel_relaxed consistent between architectures before we go through > and start modifying driver code to support different architectures. > Is there an arch problem that I'm not seeing? 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.