Thanks for adding me to the Cc list Bjorn. Hopefully my message will make it out to the netdev and linux-pci lists -- I'm not currently subscribed to them. I've explicitly marked this message to be sent in plain text but modern email agents suck with respect to this. (sigh) I have officially become a curmudgeon. So, officially, Relaxed Ordering should be a Semantic Noop as far as PCIe transfers are concerned, as long as you don't care what order the PCIe Transaction Layer Packets are processed in by the target PCIe Fabric End Point. Basically, if you have some number of back-to-back PCIe TLPs between two Fabric End Points {A} -> {B} which have the Relaxed Ordering Attribute set, the End Point {B} receiving these RO TLPs may process them in any order it likes. When a TLP without Relaxed Ordering is sent {A} -> {B}, all preceding TLPs with Relaxed Ordering set must be processed by {B} prior to processing the TLP without Relaxed Ordering set. In this sense, a TLP without Relaxed Ordering set is something akin to a "memory barrier". All of this is covered in Section 2.4.1 of the PCIe 3.0 Specification (PCI Express(r) Base Specification Revision 3.0 November 10, 2010). The advantage of using Relaxed Ordering (which is heavily used when sending data to Graphics Cards as I understand it), is that the PCIe Endpoint can potentially optimize the processing order of RO TLPs with things like a local multi-channel Memory Controller in order to achieve the highest transfer bandwidth possible. However, we have discovered at least two PCIe 3.0 Root Complex implementations which have problems with TLPs directed at them with the Relaxed Ordering Attribute set and I'm in the process of working up a Linux Kernel PCI "Quirk" to allow those PCIe End Points to be marked as "not being advisable to send RO TLPs to". These problems range from "mere" Performance Problems to outright Data Corruption. I'm working with the vendors of these ... "problematic" Root Complex implementations and hope to have this patch submitted to the linux-pci list by tomorrow. By the way, it's important to note that just because, say, a Root Complex has problems with RO TLPs directed at it, that doesn't mean that you want to avoid all use of Relaxed Ordering within the PCIe Fabric. For instance, with the vendor whose Root Complex has a Performance Problem with RO TLPs directed at it, it's perfectly reasonable -- and desired -- to use Relaxed Ordering in Peer-to-Peer traffic. Say for instance, with an NVMe <-> Ethernet application. Casey