[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200629193316.GA3283437@bjorn-Precision-5520>
Date: Mon, 29 Jun 2020 14:33:16 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Aya Levin <ayal@...lanox.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Saeed Mahameed <saeedm@...lanox.com>,
"mkubecek@...e.cz" <mkubecek@...e.cz>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Tariq Toukan <tariqt@...lanox.com>, linux-pci@...r.kernel.org,
Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>,
Ding Tianhong <dingtianhong@...wei.com>,
Casey Leedom <leedom@...lsio.com>
Subject: Re: [net-next 10/10] net/mlx5e: Add support for PCI relaxed ordering
[+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
Powered by blists - more mailing lists