From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5243CC433DF for ; Mon, 29 Jun 2020 19:33:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23EC6206E2 for ; Mon, 29 Jun 2020 19:33:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593459220; bh=S0YdjtPRSSlnoNdihph14QS32xSkaKxF4OYCSio0GLE=; h=Date:From:To:Cc:Subject:In-Reply-To:List-ID:From; b=0Vzjom4M1u3GdKH/3U9uaG+g/6rKzJPL64YK/vnO24yayuAahMxF5oRWFEtlhgRAu gyAx9DLi3cGr2qDV5glIxpZC6syj9XXXvCvjds2tWFYFyjM7+CwlY7ZSyOAaPlnRsN TKp1jgA8JlMtsml2EJCZs+uk92+2kFXYPmco5X2c= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731795AbgF2Tdj (ORCPT ); Mon, 29 Jun 2020 15:33:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:42512 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730482AbgF2TdT (ORCPT ); Mon, 29 Jun 2020 15:33:19 -0400 Received: from localhost (mobile-166-170-222-206.mycingular.net [166.170.222.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BA31A206E2; Mon, 29 Jun 2020 19:33:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593459199; bh=S0YdjtPRSSlnoNdihph14QS32xSkaKxF4OYCSio0GLE=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=opm5/3ZKjNT8OrAL+IyGlJIOqrB869sIflfMIebZ+o5mNYTqOegs/4sBzCzNYVZxI Jm+XxAYDkrNFpAmyh04dupvYYCtLyFxJUJqAWShS8dXKFcBeH9nBs+z+ruWIQA5Yo6 EgXpkLslb1j2PttdG0sCiQRzqTqZ5B3NV2QBzujM= Date: Mon, 29 Jun 2020 14:33:16 -0500 From: Bjorn Helgaas To: Aya Levin Cc: Jakub Kicinski , Saeed Mahameed , "mkubecek@suse.cz" , "davem@davemloft.net" , "netdev@vger.kernel.org" , Tariq Toukan , linux-pci@vger.kernel.org, Alexander Duyck , Ashok Raj , Ding Tianhong , Casey Leedom Subject: Re: [net-next 10/10] net/mlx5e: Add support for PCI relaxed ordering Message-ID: <20200629193316.GA3283437@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org [+cc Ashok, Ding, Casey] On Mon, Jun 29, 2020 at 12:32:44PM +0300, Aya Levin wrote: > I wanted to turn on RO on the ETH driver based on > pcie_relaxed_ordering_enabled(). > From my experiments I see that pcie_relaxed_ordering_enabled() return true > on Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz. This CPU is from Haswell > series which is known to have bug in RO implementation. In this case, I > expected pcie_relaxed_ordering_enabled() to return false, shouldn't it? Is there an erratum for this? How do we know this device has a bug in relaxed ordering? > In addition, we are worried about future bugs in new CPUs which may result > in performance degradation while using RO, as long as the function > pcie_relaxed_ordering_enabled() will return true for these CPUs. I'm worried about this too. I do not want to add a Device ID to the quirk_relaxedordering_disable() list for every new Intel CPU. That's a huge hassle and creates a real problem for old kernels running on those new CPUs, because things might work "most of the time" but not always. Maybe we need to prevent the use of relaxed ordering for *all* Intel CPUs. > That's why > we thought of adding the feature on our card with default off and enable the > user to set it. Bjorn