From: Yijing Wang <wangyijing@huawei.com>
To: Jon Mason <jdmason@kudzu.us>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Hanjun Guo <guohanjun@huawei.com>, <jiang.liu@huawei.com>,
<stable@vger.kernel.org>
Subject: Re: [PATCH -v3] PCI: update device mps when doing pci hotplug
Date: Fri, 9 Aug 2013 10:39:35 +0800 [thread overview]
Message-ID: <52045667.3080702@huawei.com> (raw)
In-Reply-To: <CAPoiz9zDQjvj1jYyW=0+0=qX60gu-FSZTHpYj2Yq2okg1WDOXA@mail.gmail.com>
>> Hi Jon,
>> Thanks for your comments!
>> I think we can improve this logic a little . As your comments in pcie_find_smpss(), if the PCI hotplug
>> slot is directly connected to the root port and there are not other devices on the fabric, then this
>> is not an issue.. So I think in this case, we can first update the newly hot added device mps as above logic.
>> if newly hot added device mpss < root port mps, then we can modify both root port device and newly hot added device
>> mps to device mpss. What do you think?
>>
>> eg.
>> Root port --------------> slot (mps is default 128,assume mpss is 256)
>> (mps 512)
>>
>> Only in this case, I think we try to update the parent device is safe.
>>
>> after update:
>> Root port --------------> slot (mps is default 128,assume mpss is 256)
>> (mps 512-->256) mps 128--->256
>
>
> Yes, but this is where it get difficult. You can only do it if the
> parent bus is the root port. Otherwise, the other devices on the bus
> will already have their MPS configured and changing the root port MPS
> will do bad things. That is why I have the check in pcie_find_smpss()
> of
>
> if (dev->is_hotplug_bridge && (!list_is_singular(&dev->bus->devices) ||
> (dev->bus->self &&
> pci_pcie_type(dev->bus->self) != PCI_EXP_TYPE_ROOT_PORT)))
>
> So, you either need to mimic this code in your new function or make
> PCIE_BUS_SAFE the default option. I'm leaning towards the latter, but
> if you need something for the stable tree then we should temporarily
> have a patch which does it the former.
>
> Thoughts?
Yes, I need one patch fix this issue in the stable tree. Will you send out
the series patch recently? Bjorn now began to review this mps code, so
this is a good chance to rework mps related codes I think.
>
>>
>>>
>>>> But if we try to configure DP 1 mps to 128B, it's not safe. its parent Upstream port still is 256.
>>>
>>> This is exactly the case that the "PERFORMANCE" option is trying to
>>> allow. If the MRRS is set to the MPS of the device, it should work.
>>> If not, then we should rip out all of the "PERFORMANCE" code. Is this
>>> something you can verify?
>>
>> Hi Jon,
>> I am not very clear about what the role of MRRS. So if I understand wrong, please correct me, thanks.
>>
>> eg.
>> DP1 ----------------> EP A
>> mps=256 mps=128
>>
>> MRRS can control the read request TLP size when the Function as a Requester.
>> So if we set the EP A MRRS to mps value(128), EP A won't generate
>> TLP larger than 128, so Request stream from EP A to DP1 is safe.
>>
>> But if EP A is as a receiver, DP 1 generate completion TLP (larger than 128) to EP A.
>> these TLPs will be discarded by EP A, right?
>
> Yes
>
>> So in my idea, If we set both mps and mrrs of EP A to 128, we can insure TLPs stream from EP A is safe.
>> But How do we guarantee that DP1 won't generate TLPs to EP A is larger than 128?
>
> The device will never do any reads of larger than the MRRS, but writes
> to the device are an issue. Assuming that all I/O is between CPU/RAM
> and the device and there are no peer-to-peer transfers, we should be
> safe (but is that a safe assumption?). So my question to you is that
> the setup you have that is failing due to MPS sizes being off, can you
> set the only MRRS to 128 and get it working?
I don't have PCIe analyzer, so I can not catch TLP, I'm not sure the TLPs size in stream.
my test is using ping $dest_ip -s 65500
local machine remote machine
IP: 128.5.160.31 IP: 128.5.160.28
Root port ---------------->Endpoint device(bnx2 NIC)
00:01.0 01:00.1
default setting
Root Port(00:01.0):
Capabilities: [90] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag+ RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
Endpoint device(01:00.1)
Capabilities: [ac] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
test1:
change root port mps to 256
Root port ---------------->EndPoint device(bnx2 NIC)
mps=256 (default 128) mps=128
mrrs=128 mrrs=512(default)
result:
ping 128.5.160.28(remote ip) -s 65500 ----->fail
ping 128.5.160.31(remove machine ping local ip)------->fail
test2:
change root port mps to 256, EP device mrrs to 128
Root port ---------------->EndPoint device(bnx2 NIC)
mps=256 (default 128) mps=128
mrrs=128 mrrs=128(default 512)
result:
ping 128.5.160.28(remote ip) -s 65500 ----->success
ping 128.5.160.31(remove machine ping local ip)------->success
It seems change mrrs to 128 take effect.
Thanks!
Yijing.
prev parent reply other threads:[~2013-08-09 2:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-06 8:09 [PATCH -v3] PCI: update device mps when doing pci hotplug Yijing Wang
2013-08-06 23:45 ` Jon Mason
2013-08-07 1:52 ` Yijing Wang
2013-08-07 16:56 ` Jon Mason
2013-08-08 2:48 ` Yijing Wang
2013-08-09 0:47 ` Jon Mason
2013-08-09 2:39 ` Yijing Wang [this message]
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=52045667.3080702@huawei.com \
--to=wangyijing@huawei.com \
--cc=bhelgaas@google.com \
--cc=guohanjun@huawei.com \
--cc=jdmason@kudzu.us \
--cc=jiang.liu@huawei.com \
--cc=linux-pci@vger.kernel.org \
--cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).