linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Myron Stowe <myron.stowe@gmail.com>
To: Radjendirane Codandaramane <radjendirane.codanda@microsemi.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	Ron Yuan <ron.yuan@memblaze.com>,
	Sinan Kaya <okaya@codeaurora.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Bo Chen <bo.chen@memblaze.com>,
	William Huang <william.huang@memblaze.com>,
	Fengming Wu <fengming.wu@memblaze.com>,
	Jason Jiang <jason.jiang@microsemi.com>,
	Ramyakanth Edupuganti <Ramyakanth.Edupuganti@microsemi.com>,
	William Cheng <william.cheng@microsemi.com>,
	"Kim Helper (khelper)" <khelper@micron.com>,
	Linux PCI <linux-pci@vger.kernel.org>
Subject: Re: One Question About PCIe BUS Config Type with pcie_bus_safe or pcie_bus_perf On NVMe Device
Date: Wed, 24 Jan 2018 09:29:45 -0700	[thread overview]
Message-ID: <CAL-B5D1bjmOCe3bCwEyq4Mpsaasss4GeL6E2B1RoRhY9uC6_Ew@mail.gmail.com> (raw)
In-Reply-To: <b93a4fb1ec42480596b8d1a2b525e8f1@microsemi.com>

Radjendirane,

I've struggled with a response to your latest posting all
night.  I don't want to come off as offensive or terse as happens all too
often on linux mail lists, all that does is shut things down unnecessarly
without relaying any information that is being sought.

Bjorn is just one person trying to keep up with this entire list.  On this
particular topic he has taken considerable time explaining, and answering
peoples specific questions, as to how Linux currently handles PCIe MPS and
MRRS settings.  As such, it was quite surprising to see your
latest posting as the majority of the content had already
been covered - the exact same questions/points - in great
detail.

We should respect Bjorn's time as much as possible and "do our
homework"; in this specific case, take the time to read the entire thread,
carefully, as that would have circumvented this awkward and frustrating
situation.  If there are still questions on covered topics, then ask the
questions at that point (i.e. use proper response techniques to preserve
context for all; don't just repeat a question much later in the thread that
has already been discussed).

Again, I'm not trying to shut you down.


As Sinan pointed out in the thread's inception:
  "Please use mailing list email syntax moving forward. (inline and 75
  characters per line)".

On Tue, Jan 23, 2018 at 4:50 PM, Radjendirane Codandaramane
<radjendirane.codanda@microsemi.com> wrote:
> Hi Bjorne,

Bjorn

>
> Ceiling the MRRS to the MPS value in order to guarantee the interoperabil=
ity in pcie_bus_perf mode does not make sense. A device can make a memrd re=
quest according to the MRRS setting (which can be higher than its MPS), but=
 the completer has to respect the MPS and send completions accordingly. As =
an example, system can configure MPS=3D128B and MRRS=3D4K, where an endpoin=
t can a make 4K MemRd request, but the completer has to send completions as=
 128B TLPs, by respecting the MPS setting. MRRS does not force a device to =
use higher MPS value than it is configured to.

This was covered by the very first topic in Bjorn's first reply within the
thread...

>
> Another factor that need to be considered for storage devices is that sup=
port of T10 Protection Information (DIF). For every 512B or 4KB, a 8B PI is=
 computed and inserted or verified, which require the 512B of data to arriv=
e in sequence. If the MRRS is < 512B, this might pose out of order completi=
ons to the storage device, if the EP has to submit multiple outstanding rea=
d requests in order to achieve higher performance. This would be a challeng=
e for the storage endpoints that process the T10 PI inline with the transfe=
r, now they have to store and process the 512B sectors once they receive al=
l the TLPs for that sector.

The "T10" aspects are new and I've not heard about them before.  On the
surface they seem to be storage device specific.  If that is indeed the
case then there seems to be some mixing of two, distinctly different,
things.  PCIe TLPs, MPS, MRRS, ..., are all PCIe defined items that are
covered by its specification.  Expecting that T10 specifics can be
intermixed within PCIe's protocol doesn't make any sense and sounds much
more like something that will have to be taken care of at the controller's
level.   Perhaps I'm  way off base here, we'll have to hear more about this
to come to some understanding.

>
> So, it is better to decouple the MRRS and MPS in pcie_bus_perf mode. Like=
 stated earlier in the thread, provide an option to configure MRRS separate=
ly in pcie_bus_perf mode.

This also has been brought up twice already, and covered in the prior
responses...

>
> Regards,
> Radj.

  reply	other threads:[~2018-01-24 16:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <SH2PR01MB106A1E21DEB5FE3FFB3D61C83E90@SH2PR01MB106.CHNPR01.prod.partner.outlook.cn>
     [not found] ` <ef16a3cc-b641-a30d-644a-7940e340eb3e@codeaurora.org>
     [not found]   ` <SHAPR01MB173A5EA1677C2138CB528F2FEE90@SHAPR01MB173.CHNPR01.prod.partner.outlook.cn>
     [not found]     ` <5727b0b1-f0d5-7c78-373e-fc9d1bd662d2@codeaurora.org>
     [not found]       ` <CABhMZUU0643U-qVc9ymA+1PMZToSLFm2dg8-cu=iQ2LGw2Pi8Q@mail.gmail.com>
     [not found]         ` <SHAPR01MB173A36104635A8BFF9A83E1FEE80@SHAPR01MB173.CHNPR01.prod.partner.outlook.cn>
2018-01-18 16:24           ` One Question About PCIe BUS Config Type with pcie_bus_safe or pcie_bus_perf On NVMe Device Sinan Kaya
2018-01-19 20:51             ` Bjorn Helgaas
2018-01-20 19:20               ` Sinan Kaya
2018-01-20 19:29                 ` Sinan Kaya
2018-01-22 21:36                 ` Bjorn Helgaas
2018-01-22 22:04                   ` Sinan Kaya
2018-01-22 22:51                     ` Bjorn Helgaas
2018-01-22 23:24                       ` Sinan Kaya
2018-01-23  0:16                         ` Bjorn Helgaas
2018-01-23  2:27                           ` Sinan Kaya
2018-01-23 13:25                             ` Ron Yuan
2018-01-23 14:01                               ` Ron Yuan
2018-01-23 17:48                                 ` Bjorn Helgaas
2018-01-23 18:07                                   ` Bjorn Helgaas
2018-01-23 14:38                               ` Bjorn Helgaas
2018-01-23 23:50                                 ` Radjendirane Codandaramane
2018-01-24 16:29                                   ` Myron Stowe [this message]
2018-01-24 17:59                                     ` Ron Yuan
2018-01-24 18:01                                   ` Bjorn Helgaas
2018-01-31  8:40                                     ` Ron Yuan
2018-02-01  0:01                                       ` Myron Stowe
2018-02-01  0:13                                         ` Sinan Kaya
2018-02-01  3:37                                           ` Bjorn Helgaas
2018-02-01 15:14                                             ` Sinan Kaya
2018-02-05  1:02                                               ` Sinan Kaya

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=CAL-B5D1bjmOCe3bCwEyq4Mpsaasss4GeL6E2B1RoRhY9uC6_Ew@mail.gmail.com \
    --to=myron.stowe@gmail.com \
    --cc=Ramyakanth.Edupuganti@microsemi.com \
    --cc=bhelgaas@google.com \
    --cc=bo.chen@memblaze.com \
    --cc=fengming.wu@memblaze.com \
    --cc=helgaas@kernel.org \
    --cc=jason.jiang@microsemi.com \
    --cc=khelper@micron.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=okaya@codeaurora.org \
    --cc=radjendirane.codanda@microsemi.com \
    --cc=ron.yuan@memblaze.com \
    --cc=william.cheng@microsemi.com \
    --cc=william.huang@memblaze.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).