public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING
Date: Tue, 8 Aug 2017 18:22:00 -0500	[thread overview]
Message-ID: <20170808232200.GO16580@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <1501917313-9812-2-git-send-email-dingtianhong@huawei.com>

On Sat, Aug 05, 2017 at 03:15:10PM +0800, Ding Tianhong wrote:
> From: Casey Leedom <leedom@chelsio.com>
> 
> The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that
> Relaxed Ordering (RO) attribute should not be used for Transaction Layer
> Packets (TLP) targetted towards these affected root complexes. Current list
> of affected parts include some Intel Xeon processors root complex which suffers from
> flow control credits that result in performance issues. On these affected
> parts RO can still be used for peer-2-peer traffic. AMD A1100 ARM ("SEATTLE")
> Root complexes don't obey PCIe 3.0 ordering rules, hence could lead to
> data-corruption.

This needs to include a link to the Intel spec
(https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf,
sec 3.9.1).

It should also include a pointer to the AMD erratum, if available, or
at least some reference to how we know it doesn't obey the rules.

Ashok, thanks for chiming in.  Now that you have, I have a few more
questions for you:

  - Is the above doc the one you mentioned as being now public?
  
  - Is this considered a hardware erratum?
  
  - If so, is there a pointer to that as well?
  
  - If this is not considered an erratum, can you provide any guidance
    about how an OS should determine when it should use RO?
    
Relying on a list of device IDs in an optimization manual is OK for an
erratum, but if it's *not* an erratum, it seems like a hole in the
specs because as far as I know there's no generic way for the OS to
discover whether to use RO.

Bjorn

  reply	other threads:[~2017-08-08 23:22 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-05  7:15 [PATCH v9 0/4] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong
2017-08-05  7:15 ` [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING Ding Tianhong
2017-08-08 23:22   ` Bjorn Helgaas [this message]
2017-08-09  1:40     ` Casey Leedom
2017-08-09  3:02       ` Bjorn Helgaas
2017-08-09 12:17         ` Ding Tianhong
2017-08-09 16:36           ` Casey Leedom
2017-08-09 15:58     ` Raj, Ashok
2017-08-09 16:46       ` Casey Leedom
2017-08-09 18:00         ` Raj, Ashok
2017-08-09 20:11           ` Casey Leedom
2017-08-05  7:15 ` [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported Ding Tianhong
2017-08-09  2:22   ` Bjorn Helgaas
2017-08-09  3:25     ` Bjorn Helgaas
2017-08-09 13:42       ` Ding Tianhong
2017-08-09 12:33     ` Casey Leedom
2017-08-09 13:23     ` Ding Tianhong
2017-08-05  7:15 ` [PATCH v9 3/4] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong
2017-08-05  7:15 ` [PATCH v9 4/4] net/cxgb4vf: " Ding Tianhong
2017-08-07  3:47 ` [PATCH v9 0/4] Add " David Miller
2017-08-07  4:13   ` Ding Tianhong
2017-08-07 21:14     ` David Miller
2017-08-08  1:56       ` Bjorn Helgaas

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=20170808232200.GO16580@bhelgaas-glaptop.roam.corp.google.com \
    --to=helgaas@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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