From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752649AbdGHCFE (ORCPT ); Fri, 7 Jul 2017 22:05:04 -0400 Received: from mail-bl2nam02on0124.outbound.protection.outlook.com ([104.47.38.124]:3610 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751751AbdGHCFC (ORCPT ); Fri, 7 Jul 2017 22:05:02 -0400 From: Casey Leedom To: Alexander Duyck CC: Ding Tianhong , "ashok.raj@intel.com" , "helgaas@kernel.org" , "Michael Werner" , Ganesh GR , "asit.k.mallick@intel.com" , "patrick.j.cramer@intel.com" , "Suravee.Suthikulpanit@amd.com" , "Bob.Shaw@amd.com" , "l.stach@pengutronix.de" , "amira@mellanox.com" , "gabriele.paoloni@huawei.com" , "David.Laight@aculab.com" , "jeffrey.t.kirsher@intel.com" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "mark.rutland@arm.com" , "robin.murphy@arm.com" , "davem@davemloft.net" , "linux-arm-kernel@lists.infradead.org" , "netdev@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Thread-Topic: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Thread-Index: AQHS61FojWeFUbyhA0yWrtj3U/TwHqJI9lhqgAAypGyAAAfkgIAAEO11 Date: Sat, 8 Jul 2017 02:04:56 +0000 Message-ID: References: <1498133721-21152-1-git-send-email-dingtianhong@huawei.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=chelsio.com; x-originating-ip: [24.130.148.141] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;MWHPR12MB1438;7:H3HPailFJ+G6iMSFDd3MMQGPLiOO61JhUw2nYxvtrBBCPSLOlbCvGJiZGOr7aHg34K6fe0l0rrm2tfxkR78lC+My/vSPMjaYsPR1ddp2PDYPR/w/4oThxx2WWWkCnT8S0XLNU8Qu9G8s1xG4SxO9TK9q/QTMIbuZPA6gGNsi5zcw1NKwTKwYH9DTS94tEO6X+GduJdN4Hb7nZuPf1XvWNjwEdZIHkb6TbsC9pH1xmIDXOhgPTc79WvvMUSCWHgiKtACo2eTuniyNu6NzPJfqcUZjm2J0bYVNmbpTOjonR0+we579fVLgy8ctwMJ52eRGcwrQMzFbkoSdMYPjaOSk9q/0iemP8UYcDBaAUnZGXOpl91/2qTHtrNcOubqbe/69vaj2yrQzolS8SvLs0sgKRtLCVtGqP1PTbBQ1RsdNd17CR2oAyLl9JG2MjAgaRy2H6m83s+43vu+DacxWkUMJE1F5FuYxKzLMCXYPfhelaxmZljE2yJ2hdghHXowy2trd6e7WO+GX+TytkdCYIsIZZZJJtmObD7bhXFU8nlUKtl19YZdQ1QjrpBrjqQVeovrwEWdcgahiAAcTlUmjbW0qs7EFLxUyB23PLOgLuttNeLXGrL9PEFxv4usFWtVkCziUVa3IZgvJxSPCswyA35KWrzTBw+Tr8ACr2vUvgh0EcsekXOj2H/OAzSlwAUVlXSm3GsTWgY5OSBSwzCerOl+1Y8E2GuwJ6BdXvVCiakRTGOcR/JucHc07KPbxkhsAKYUqX1RCjBgQQDCdInaS8F/Pmxt8CiGOEFV/gRbUC/a3CjQ= x-ms-office365-filtering-correlation-id: 7885e95d-718a-4895-7d8f-08d4c5a5bb37 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:MWHPR12MB1438; x-ms-traffictypediagnostic: MWHPR12MB1438: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910072)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(2016111802025)(6043046)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:MWHPR12MB1438;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:MWHPR12MB1438; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39840400002)(39400400002)(39410400002)(51914003)(8676002)(53936002)(3660700001)(2906002)(3280700002)(93886004)(189998001)(33656002)(8936002)(81166006)(7696004)(14454004)(74316002)(305945005)(7736002)(7416002)(5660300001)(478600001)(4326008)(6916009)(66066001)(229853002)(9686003)(2950100002)(55016002)(38730400002)(99286003)(110136004)(2900100001)(54906002)(39060400002)(6246003)(8666007)(3846002)(6116002)(102836003)(25786009)(86362001)(6436002)(6506006)(77096006)(50986999)(575784001)(54356999)(76176999);DIR:OUT;SFP:1102;SCL:1;SRVR:MWHPR12MB1438;H:MWHPR12MB1600.namprd12.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;PTR:InfoNoRecords;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-OriginatorOrg: chelsio.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2017 02:04:56.4812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 065db76d-a7ae-4c60-b78a-501e8fc17095 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1438 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v6825CHu007337 Okay, thanks for the note Alexander. I'll have to look more closely at the patch on Monday and try it out on one of the targeted systems to verify the semantics you describe. However, that said, there is no way to tell a priori where a device will send TLPs. To simply assume that all TLPs will be directed towards the Root Complex is a big assumption. Only the device and the code controlling it know where the TLPs will be directed. That's why there are changes required in the cxgb4 driver. For instance, the code in drivers/net/ethernet/chelsio./cxgb4/sge.c: t4_sge_alloc_rxq() knows that it's allocating Free List Buffers in Host Memory and that the RX Queues that it's allocating in the Hardware will eventually send Ingress Data to those Free List Buffers. (And similarly for the Free List Buffer Pointer Queue with respect to DMA Reads from the host.) In that routine we explicitly configure the Hardware to use/not-use the Relaxed Ordering Attribute via the FW_IQ_CMD_FL0FETCHRO and FW_IQ_CMD_FL0DATARO flags. Basically we're conditionally setting them based on the desirability of sending Relaxed Ordering TLPs to the Root Complex. (And we would perform the same kind of check for an nVME application ... which brings us to ...) And what would be the code using these patch APIs to set up a Peer-to-Peer nVME-style application? In that case we'd need the Chelsio adapter's PCIe Capability Device Control[Relaxed Ordering Enable] set for the nVME application ... and we would avoid programming the Chelsio Hardware to use Relaxed Ordering for TLPs directed at the Root Complex. Thus we would be in a position where some TLPs being emitted by the device to Peer devices would have Relaxed Ordering set and some directed at the Root Complex would not. And the only way for that to work is if the source device's Device Control[Relaxed Ordering Enable] is set ... Finally, setting aside my disagreements with the patch, we still have the code in the cxgb4 driver which explicitly turns on its own Device Control[Relaxed Ordering Enable] in cxgb4_main.c: enable_pcie_relaxed_ordering(). So the patch is something of a loop if all we're doing is testing our own Relaxed Ordering Enable state ... Casey