linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Leedom <leedom@chelsio.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Ding Tianhong <dingtianhong@huawei.com>,
	"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: Tue, 11 Jul 2017 00:01:37 +0000	[thread overview]
Message-ID: <MWHPR12MB16008EFFC5F2792880F7E80BC8A90@MWHPR12MB1600.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAKgT0UdqoRR8XLG1o3ygUZTqEBQ4dgNaneZ-n1OSNC1AiswO_g@mail.gmail.com>


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

  reply	other threads:[~2017-07-11  0:01 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 [this message]
2017-07-11 20:33             ` Alexander Duyck
2017-07-12  9:46             ` Ding Tianhong
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=MWHPR12MB16008EFFC5F2792880F7E80BC8A90@MWHPR12MB1600.namprd12.prod.outlook.com \
    --to=leedom@chelsio.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=dingtianhong@huawei.com \
    --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=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).