Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported
From: Casey Leedom
Date: Fri Aug 04 2017 - 16:48:48 EST
| From: Raj, Ashok <ashok.raj@xxxxxxxxx>
| Sent: Friday, August 4, 2017 1:21 PM
|
| On Fri, Aug 04, 2017 at 08:20:37PM +0000, Casey Leedom wrote:
| > ...
| > As I've noted a number of times, it would be great if the Intel Hardware
| > Engineers who attempted to implement the Relaxed Ordering semantics in the
| > current generation of Root Complexes had left the ability to turn off the
| > logic which is obviously not working. If there was a way to disable the
| > logic via an undocumented register, then we could have the Linux PCI Quirk
| > do that. Since Relaxed Ordering is just a hint, it's completely legitimate
| > to completely ignore it.
|
| Suppose you are looking for the existence of a chicken bit to instruct the
| port to ignore RO traffic. So all we would do is turn the chicken bit on
| but would permit p2p traffic to be allowed since we won't turn off the
| capability as currently proposed.
|
| Let me look into that keep you posted.
Huh, I'd never heard it called a "chicken bit" before, but yes, that's what
I'm talking about.
Whenever our Hardware Designers implement new functionality in our hardware,
they almost always put in A. several "knobs" which can control fundamental
parameters of the new Hardware Feature, and B. a mechanism of completely
disabling it if necessary. This stems from the incredibly long Design ->
Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s!
It's obvious that handling Relaxed Ordering is a new Hardware Feature for
Intel's Root Complexes since previous versions simply ignored it (because
that's legal[1]). If I was a Hardware Engineer tasked with implementing
Relaxed Ordering semantics for a device, I would certainly have also
implemented a switch to turn it off in case there were unintended
consequences (performance in this case).
And if there is such a mechanism to simply disable processing of Relaxed
Ordering semantics in the Root Complex, that would be a far easier "fix" for
this problem ... and leave the code in place to continue sending Relaxed
Ordering TLPs for a future Root Complex implementation which got it right ...
Casey
[1] One can't ~quite~ just ignore the Relaxed Ordering Attribute on an
incoming Transaction Layer Packet Request: PCIe completion rules (see
section 2.2.9 of the PCIe 3.0 specificatin) require that the Relaxed
Ordering and No Snoop Attributes in a Request TLP be reflected back
verbatim in any corresponding Response TLP. (The rules for ID-Based
Ordering are more complex.)