public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: ashok.raj@intel.com (Raj, Ashok)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported
Date: Thu, 3 Aug 2017 01:31:53 -0700	[thread overview]
Message-ID: <20170803083153.GB4883@otc-nc-03> (raw)
In-Reply-To: <MWHPR12MB1600A6986E4AD13D302F2DC9C8B00@MWHPR12MB1600.namprd12.prod.outlook.com>

Hi Casey

On Wed, Aug 02, 2017 at 05:53:52PM +0000, Casey Leedom wrote:
> ? Okay, here you go.? As you can tell, it's almost a trivial copy of the
> cxgb4 patch.
> ?
> ? By the way, I realized that we have yet another hole which is likely not
> to be fixable.? If we're dealing with a problematic Root Complex, and we
> instantiate Virtual Functions and attach them to a Virtual Machine along
> with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver
> in the VM will be able to tell that it shouldn't attempt to send RO TLPs to
> the RC because it will see the state of its own PCIe Capability Device
> Control[Relaxed Ordering Enable] (a copy of the setting in the VF's
> corresponding PF), but it won't be able to change that and send non-RO TLPs
> to the RC, and RO TLPs to the NVMe device.? Oh well.

I don't understand this completely.. So your driver would know not to send RO
TLP's to root complex. But you want to send RO to the NVMe device? This is the
peer-2-peer case correct?

The issue in the current patchset is that we device to turn off the device 
capability for all devices in the hierarchy so one would expect that 
the NVMe also would have RO turned off i suppose. 

The other approach is to not turn off the device capabilty, but let the
driver do the right thing. i.e for transactions towards system memory vs. 
peer-2-peer? But since we wanted to take a big hammer approach because
some platforms there can be data-corruption and we can't let trust guest
drivers to do the right thing. This isn't something we can fix in this 
current version.

One possible approach is to provide a strict flag, where we use this heavy 
hammer approach only on platforms that have a serious implication, and the 
other is we let the driver do the right thing depending on the platform.

Worst case if the driver doesn't do the right thing, you would see perf issues
but nothing bad would happen. It would allow you to select when to turn on 
RO and when to turn it off.

Cheers,
Ashok

  reply	other threads:[~2017-08-03  8:31 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-13 14:21 [PATCH v7 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong
2017-07-13 14:21 ` [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING Ding Tianhong
2017-08-03  8:55   ` Raj, Ashok
2017-08-03 10:20     ` Ding Tianhong
2017-07-13 14:21 ` [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported Ding Tianhong
2017-07-13 21:09   ` Sinan Kaya
2017-07-14  1:26     ` Ding Tianhong
2017-07-14 13:54       ` Sinan Kaya
2017-07-22  4:19         ` Ding Tianhong
2017-07-24 15:05           ` Alex Williamson
2017-07-26 18:26             ` Casey Leedom
     [not found]               ` <CAKgT0UeAad6WArvrE71MFJywDs1wOnCF-iJRnbNLrL+knqhXeA@mail.gmail.com>
     [not found]                 ` <CAKgT0Uf5hdXUXja_jUB6_kBg6pyX8zXuOMOGzCVNgeBFMUsWqQ@mail.gmail.com>
     [not found]                   ` <CAKgT0Udn2vh6NaqZyiF69nXVnz2sT=e0ZgiDjWznhGZz-Gk+qQ@mail.gmail.com>
2017-07-26 19:05                     ` Casey Leedom
2017-07-27  1:01                       ` Ding Tianhong
2017-07-27 17:44                         ` Casey Leedom
2017-07-27 18:42                           ` Raj, Ashok
2017-07-28  2:57                             ` Ding Tianhong
2017-07-28  2:48                           ` Ding Tianhong
2017-07-27  1:08               ` Ding Tianhong
2017-07-27 17:49                 ` Alexander Duyck
2017-07-28  3:00                   ` Ding Tianhong
2017-08-02 17:53                     ` Casey Leedom
2017-08-03  8:31                       ` Raj, Ashok [this message]
2017-08-04 20:20                         ` Casey Leedom
2017-08-04 20:21                           ` Raj, Ashok
2017-08-04 20:48                             ` Casey Leedom
2017-08-07  9:04                               ` David Laight
2017-08-03  9:13   ` Raj, Ashok
2017-08-03 10:22     ` Ding Tianhong
2017-07-13 14:21 ` [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong
2017-07-13 18:14   ` Alexander Duyck
2017-07-13 18:17     ` Alexander Duyck
2017-07-14  0:00       ` Casey Leedom
     [not found]       ` <MWHPR12MB1600E5A4404EE9D97CD99F88C8AC0@MWHPR12MB1600.namprd12.prod.outlook.com>
2017-07-14 10:23         ` Ding Tianhong
2017-07-14 17:50           ` Casey Leedom

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=20170803083153.GB4883@otc-nc-03 \
    --to=ashok.raj@intel.com \
    --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