Received: by 10.213.65.68 with SMTP id h4csp1263310imn; Wed, 14 Mar 2018 14:50:49 -0700 (PDT) X-Google-Smtp-Source: AG47ELvodZtpraG4/164HfHNYszVdLWVkB24w8BJI00Uiy8tus7Em/v8JPpOvL0LLDK5H4WwARLO X-Received: by 2002:a17:902:183:: with SMTP id b3-v6mr5591269plb.80.1521064249395; Wed, 14 Mar 2018 14:50:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521064249; cv=none; d=google.com; s=arc-20160816; b=Se3yZ98mBP3uqT+CKv1htjGNRtolw46SG4dD3s5OgPuJW38kcjO6eOeYPzN/+J1clv pN0UaW1nHXkG9+VthMzPc1DRohplI5bJwpeWsBl/2VdrgcWstnvTQoKRUUVJP5yZzi96 lGL+KrdC0XUD3SGciSgyt8Ns79NyjwoKm15y7H92Wa6stTi9j1Waqhao2ZmMNRRjXZLo KNnwPUh+lrYRLj8IvUT5bBSy/UJKV2WLRlv+1Fa9JS/Wh6sXx/TlHU58TUYOGgDflB8+ 4FIJWTw1LVBYstljzcQY5KPdunuRaQeqMuEvjjFiN2Li97p9w46OYLbgHYqKtx+u39kP t6gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=BrhDvumbCZGI3l86Zb8MBZlBkbXNkecVAP7mX7ch5o8=; b=li/wdzjjdzh3IpjX/TP/GBZaepmw+DPopdDdjUagys9Z8XY8pclImzahfy3su0pK24 bqp3xqQAcfgz6QTtcm7Xun5Foom/p/lG8FX+SmpVqqgW871blurGEnFwvIKLekoqjBK9 NzCZvdeK5JyARbquiH5/pB/bQ/fBgfGYsbyeEfeS3TsEwt8AOOjcnszjBo+5wxiMpiy0 XI6KnD//2sqyloXnPgoJj5l+vQojkNtIS9/YZ5AiZx7XJy21T1c2ZYVfWCM/fwq7HVjh roNtlg3FGLS/3+WNdUTPG1DndDLJb7sahH8/ecDXom84q6CQKYjX8vKRErzr8ssJqUV6 EVqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GZUji+Oa; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a65si2451937pge.521.2018.03.14.14.50.10; Wed, 14 Mar 2018 14:50:49 -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=@gmail.com header.s=20161025 header.b=GZUji+Oa; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751857AbeCNVtE (ORCPT + 99 others); Wed, 14 Mar 2018 17:49:04 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:37866 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbeCNVtB (ORCPT ); Wed, 14 Mar 2018 17:49:01 -0400 Received: by mail-qt0-f196.google.com with SMTP id a23so5170729qtm.4; Wed, 14 Mar 2018 14:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BrhDvumbCZGI3l86Zb8MBZlBkbXNkecVAP7mX7ch5o8=; b=GZUji+OaDz7dP85Oru30EIdmky2fyrUHYLj/WTbdvYk2tuwPol0GhJxrV5QEOprbjV RJ9bEOIuINMse/kF0cRNpnOBeZNeokyek0y9Fx3Gw0aY8I+iMMKnXNEC8cjhRWcGIYRO LhBjxl0NcPepsUvFaoEV6aCH5uDMdtZIfs37hCVxiI9Nb4t7p+BfoGz7kyDYMcgMx1hn PFmM3mPUdox17FSw2zrs/YWgbcAGoicEoZa2NeashvOT32+EuX1vJyfgiXUtxTIs1E9B lukd/yFenAV6aN1H88+g2pR/vUsg1n30/ry4SXsJt6ZU2oHS5T3e7ab5ejHD8IFfBHSY vNjw== 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=BrhDvumbCZGI3l86Zb8MBZlBkbXNkecVAP7mX7ch5o8=; b=R40AXDcGKzjz+4iu/4o390xkDlsvdmK4ylTsQ0u7m3ays4L8zaR2hyLFkUDM8rjT0i /Gp7U/Cmp+IEQ+aJnQDG1JBjVa3HK9lr8ygQxmQi2Z9nD0ZUH+Y22BQPvCm/D0JmdvlG fYdbbe7LfCPpCP7UJHgGYFyTG5JQQ/P8zMVhPtgxDqk91dpcB34sC8lcDRuG4k7KpCsC f1bbqNxLQF1pzODhBbkstbUB9tI4oLdlYI1np/qZ2Jc/942a+JgQpPEht3EkEV3QPOem 2Z1AbJROF56TbyZb5DlpYKsKYQLUU/CVeihmTCQISuImhB72fvcVMdlUhmDfh23PNSxC g2vg== X-Gm-Message-State: AElRT7EUGr7b6fZvG0UkIH6zLprZJnIfBUp/HFD6cELOm7fmNpCL1nja W1K2cJVwr529saSgDp4KnHH5b36guTlLq0gKmRg= X-Received: by 10.200.57.117 with SMTP id t50mr9937253qtb.22.1521064140975; Wed, 14 Mar 2018 14:49:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.89.138 with HTTP; Wed, 14 Mar 2018 14:49:00 -0700 (PDT) In-Reply-To: <2a4f4dec64b7462ae64152f6c2df9754@codeaurora.org> 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: Alexander Duyck Date: Wed, 14 Mar 2018 14:49:00 -0700 Message-ID: Subject: Re: [PATCH 7/7] ixgbevf: eliminate duplicate barriers on weakly-ordered archs To: Sinan Kaya 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: >>> >>> +/* Assumes caller has executed a write barrier to order memory and >>> device >>> + * requests. >>> + */ >>> static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32 >>> value) >>> { >>> - writel(value, ring->tail); >>> + writel_relaxed(value, ring->tail); >>> } >> >> >> Why not put the wmb() in this function, or just get rid of the wmb() >> in the rest of the file and keep this as writel? That way, you can >> avoid the comment and the risk that comes with it. > > > > Sure, both solutions will work. I want to see what the maintainer prefers. I > can repost accordingly. Actually I would argue this whole patch set is pointless. For starters why is it we are only updating the Intel Ethernet drivers here? 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. 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. 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.