Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp11581415imu; Tue, 1 Jan 2019 02:23:15 -0800 (PST) X-Google-Smtp-Source: ALg8bN4ZmkeFD51VJB4+dqsRznh6OohOKUbTTuCh2nAH/9Btvg9OQz1T+zuoL5g10XcPF1tklyq1 X-Received: by 2002:a17:902:981:: with SMTP id 1mr38895189pln.142.1546338195052; Tue, 01 Jan 2019 02:23:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546338195; cv=none; d=google.com; s=arc-20160816; b=T05HfgfbsPgkHx65DcwLOmvNCDoj04MBeccyXKf8cyLRt7Q4wnq6TGarml/WK3uJay 0xD+nZgkjsJtRMjdr3X6hhM4sql4kc8wnECcRSvvax0cN/7jIzuerAkWDBsTZKoVRcCk jp5JhWFxQMNwQvU1L8Ol4eqn5C9yNEnZsR6X1lP2dGWSZKY0xsHFzCi/oxN32M16DCWQ vd1EMmHicOspvN9p0x0YX1nYq3iwLg43tUjQjHWpc04V1ZBuWSrIG5ggQ0ig04SDnh6H pmeWuPHF1QCq4FcIQeEid7DW+06nwxbdM6IlMPgjPSEue706b95kDUcAjsi9a9Z0Pu3v oJJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from; bh=uh7rRwMvoa0uehvWR12ofoz4RShTxBy4Cd4PxE+loYQ=; b=0d4rYcQjeTZafVy8/b6eZRWLuUHL+u8rOs2y7krwsARtUvGAE4tjJjrHw5bcmghxDD tDmfe+nCYP8vXmwaoQSbHCSgxg9h32bZZR2MYRRNi7BRI7jyv5djurcPEl8TqtQNY9Gn oQzgA3YaE9/h9EIllHASKLJWkIpmZsehoqtW2tkTpEsgAUcVoZDiApNDu2k14uxWGTTr LJB9kIJqQ87rVh5MFIvc3Vz50B8BWNX0imA4Op69c2NpwFUuUA5Jd3y4hHqd1AF/RfAO po5AT5trSug8U/JlSFSN7JKRtYNDUg8VeB5kilR206dSeDhx+qloTMA9rPUHdX/MzXRN 8/Cg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h3si26882625pll.116.2019.01.01.02.22.44; Tue, 01 Jan 2019 02:23:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728180AbfAAGhM convert rfc822-to-8bit (ORCPT + 99 others); Tue, 1 Jan 2019 01:37:12 -0500 Received: from dfwrgout.huawei.com ([206.16.17.72]:2062 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727611AbfAAGhL (ORCPT ); Tue, 1 Jan 2019 01:37:11 -0500 X-Greylist: delayed 972 seconds by postgrey-1.27 at vger.kernel.org; Tue, 01 Jan 2019 01:37:11 EST Received: from DFWEML703-CAH.china.huawei.com (unknown [172.18.9.221]) by Forcepoint Email with ESMTP id ED5C087E15F02; Tue, 1 Jan 2019 00:20:55 -0600 (CST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by DFWEML703-CAH.china.huawei.com (10.193.5.177) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 31 Dec 2018 22:20:57 -0800 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.185]) by SJCEML701-CHM.china.huawei.com ([169.254.3.129]) with mapi id 14.03.0415.000; Mon, 31 Dec 2018 22:20:49 -0800 From: Eric Wehage To: Bjorn Helgaas , yu CC: "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Logan Gunthorpe" , Stephen Bates , Jonathan Cameron , Alexander Duyck Subject: RE: How to force RC to forward p2p TLPs Thread-Topic: How to force RC to forward p2p TLPs Thread-Index: AQHUnx5arrCTMaIaJ0ieNs1Uu8mqA6WZ9IxA Date: Tue, 1 Jan 2019 06:20:48 +0000 Message-ID: References: <20181229022923.GA159477@google.com> In-Reply-To: <20181229022923.GA159477@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.247.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There is no method to force an RC to forward requests p2p. RC's are also not required to support p2p and whether they do or not is implementation specific. There is also currently no PCIe based standard to determine whether an RC supports p2p or in what capacity. Also, even if p2p is supported, it might not be supported in a system that enables Virtualization (the Virtualization would have to setup p2p tables to allow it). There is currently a PCIe ECR that has been submitted, but is undergoing review, that defines a PCIe capability for bridge devices (Root Ports and Switch Downstream Ports) that would allow them to advertise what level of p2p is supported by the device. Eric Wehage Huawei Principal Engineer, PCIe -----Original Message----- From: Bjorn Helgaas [mailto:helgaas@kernel.org] Sent: Friday, December 28, 2018 6:29 PM To: yu Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; Logan Gunthorpe ; Stephen Bates ; Jonathan Cameron ; Eric Wehage ; Alexander Duyck Subject: Re: How to force RC to forward p2p TLPs [+cc Logan, Stephen, Jonathan, Eric, Alex] On Sat, Dec 22, 2018 at 12:50:19PM +0800, yu wrote: > Hi all, > > We have a PCIE card which has a PEX8732 switch on-board, and there > are two endpoint SOCs like graphic decoder behind the switch, and by > default the ACS is enabled in 8732. > > We use the p2p DMA to transfer data between these two endpoint SOCs, > and if the host server is not enable ACS in BIOS, the p2p works well, > but when ACS is enabled in BIOS, the p2p is always failed. With the > help of a protocol analyzer, we can see that the TLP is redirected to > RC, and RC just discard it. > > I tried to find how to make RC forward redirected TLP to its original > target, but nothing found, it seems this is highly related to the RC > vendors. > > In the PCIE 4.0 spec, the section of the RC behavior of the p2p > request redirect said that ''implementation-specific logic within the > RC that determines whether the request is directed towards its > original target, or blocked as an ACS Violation error. the algorithms > and specific controls for making this determination are not > architected by this spec''. > > > So is there some spec or document to describe how to set the RC? Any > suggestion is appreciated. Not that I'm aware of, but the folks I cc'd would know a lot more about this area. Bjorn