From: Ding Tianhong <dingtianhong@huawei.com>
To: Casey Leedom <leedom@chelsio.com>,
Alexander Duyck <alexander.duyck@gmail.com>
Cc: "ashok.raj@intel.com" <ashok.raj@intel.com>,
"helgaas@kernel.org" <helgaas@kernel.org>,
Michael Werner <werner@chelsio.com>,
Ganesh GR <ganeshgr@chelsio.com>,
"asit.k.mallick@intel.com" <asit.k.mallick@intel.com>,
"patrick.j.cramer@intel.com" <patrick.j.cramer@intel.com>,
"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
"Bob.Shaw@amd.com" <Bob.Shaw@amd.com>,
"l.stach@pengutronix.de" <l.stach@pengutronix.de>,
"amira@mellanox.com" <amira@mellanox.com>,
"gabriele.paoloni@huawei.com" <gabriele.paoloni@huawei.com>,
"David.Laight@aculab.com" <David.Laight@aculab.com>,
"jeffrey.t.kirsher@intel.com" <jeffrey.t.kirsher@intel.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
Date: Wed, 12 Jul 2017 17:46:40 +0800 [thread overview]
Message-ID: <16d18af6-f578-ef8a-a52e-46ec975e59e0@huawei.com> (raw)
In-Reply-To: <MWHPR12MB16008EFFC5F2792880F7E80BC8A90@MWHPR12MB1600.namprd12.prod.outlook.com>
On 2017/7/11 8:01, Casey Leedom wrote:
>
> Hey Alexander,
>
> Okay, I understand your point regarding the "most likely scenario" being
> TLPs directed upstream to the Root Complex. But I'd still like to make sure
> that we have an agreed upon API/methodology for doing Peer-to-Peer with
> Relaxed Ordering and no Relaxed Ordering to the Root Complex. I don't see
> how the proposed APIs can be used in that fashion.
>
> Right now the proposed change for cxgb4 is for it to test its own PCIe
> Capability Device Control[Relaxed Ordering Enable] in order to use that
> information to program the Chelsio Hardware to emit/not emit upstream TLPs
> with the Relaxed Ordering Attribute set. But if we're going to have the
> mixed mode situation I describe, the PCIe Capability Device Control[Relaxed
> Ordering Enable] will have to be set which means that we'll be programming
> the Chelsio Hardware to send upstream TLPs with Relaxed Ordering Enable to
> the Root Complex which is what we were trying to avoid in the first place ...
>
> [[ And, as I noted on Friday evening, the currect cxgb4 Driver hardwires
> the Relaxed Ordering Enable on early dureing device probe, so that
> would minimally need to be addressed even if we decide that we don't
> ever want to support mixed mode Relaxed Ordering. ]]
>
> We need some method of telling the Chelsio Driver that it should/shouldn't
> use Relaxed Ordering with TLPs directed at the Root Complex. And the same
> is true for a Peer PCIe Device.
>
> It may be that we should approach this from the completely opposite
> direction and instead of having quirks which identify problematic devices,
> have quirks which identify devices which would benefit from the use of
> Relaxed Ordering (if the sending device supports that). That is, assume the
> using Relaxed Ordering shouldn't be done unless the target device says "I
> love Relaxed Ordering TLPs" ... In such a world, an NVMe or a Graphics
> device might declare love of Relaxed Ordering and the same for a SPARC Root
> Complex (I think that was your example).
>
> By the way, the sole example of Data Corruption with Relaxed Ordering is
> the AMD A1100 ARM SoC and AMD appears to have given up on that almost as
> soon as it was released. So what we're left with currently is a performance
> problem on modern Intel CPUs ... (And hopefully we'll get a Technical
> Publication on that issue fairly soon.)
>
> Casey
>
Hi Casey:
After the long discuss, I think If the PCIe Capability Device Control[Relaxed Ordering
Enable] to be cleared when the platform's RC has some problematic for RO didn't break
anything in your driver, I think you could choose to check the
(!pci_dev_should_disable_relaxed_ordering(root)) in the code to to enable
ROOT_NO_RELAXED_ORDERING for your adapter, and enable the PCIe Capability Device Control
[Relaxed Ordering Enable] bit when you need it, I think we don't have much gap here.
And we could leave the pear-to-pear situation to be fixed later.
Thanks
Ding
> .
>
next prev parent reply other threads:[~2017-07-12 9:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 12:15 [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong
2017-06-22 12:15 ` [PATCH v6 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING Ding Tianhong
2017-06-22 12:15 ` [PATCH v6 2/3] PCI: Enable PCIe Relaxed Ordering if supported Ding Tianhong
2017-06-22 12:15 ` [PATCH v6 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong
2017-06-29 5:47 ` [PATCH v6 0/3] Add " Ding Tianhong
2017-07-06 12:58 ` Ding Tianhong
2017-07-06 17:17 ` Bjorn Helgaas
2017-07-07 1:03 ` Ding Tianhong
2017-07-07 21:48 ` Casey Leedom
2017-07-08 0:30 ` Casey Leedom
2017-07-08 0:47 ` Alexander Duyck
2017-07-08 2:04 ` Casey Leedom
2017-07-08 3:37 ` Alexander Duyck
2017-07-11 0:01 ` Casey Leedom
2017-07-11 20:33 ` Alexander Duyck
2017-07-12 9:46 ` Ding Tianhong [this message]
2017-07-13 0:52 ` Casey Leedom
2017-07-13 1:18 ` Ding Tianhong
2017-07-13 2:28 ` Casey Leedom
2017-07-10 10:49 ` Ding Tianhong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16d18af6-f578-ef8a-a52e-46ec975e59e0@huawei.com \
--to=dingtianhong@huawei.com \
--cc=Bob.Shaw@amd.com \
--cc=David.Laight@aculab.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=alexander.duyck@gmail.com \
--cc=amira@mellanox.com \
--cc=ashok.raj@intel.com \
--cc=asit.k.mallick@intel.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=gabriele.paoloni@huawei.com \
--cc=ganeshgr@chelsio.com \
--cc=helgaas@kernel.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=l.stach@pengutronix.de \
--cc=leedom@chelsio.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.org \
--cc=patrick.j.cramer@intel.com \
--cc=robin.murphy@arm.com \
--cc=werner@chelsio.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).