From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755273AbbITKfu (ORCPT ); Sun, 20 Sep 2015 06:35:50 -0400 Received: from mail-am1on0056.outbound.protection.outlook.com ([157.56.112.56]:48752 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755206AbbITKfk (ORCPT ); Sun, 20 Sep 2015 06:35:40 -0400 Authentication-Results: spf=pass (sender IP is 193.47.165.134) smtp.mailfrom=mellanox.com; vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=pass action=none header.from=mellanox.com; Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource To: Jason Gunthorpe , Parav Pandit References: <55F25781.20308@redhat.com> <20150911145213.GQ8114@mtj.duckdns.org> <1828884A29C6694DAF28B7E6B8A82373A903A586@ORSMSX109.amr.corp.intel.com> <20150911194311.GA18755@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373A903A5DB@ORSMSX109.amr.corp.intel.com> <20150914172832.GA21652@obsidianresearch.com> <20150914201840.GA8764@obsidianresearch.com> <20150915034549.GA27847@obsidianresearch.com> CC: "Hefty, Sean" , Tejun Heo , "Doug Ledford" , "cgroups@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "lizefan@huawei.com" , Johannes Weiner , Jonathan Corbet , "james.l.morris@oracle.com" , "serge@hallyn.com" , Or Gerlitz , Matan Barak , "raindel@mellanox.com" , "akpm@linux-foundation.org" , "linux-security-module@vger.kernel.org" From: Haggai Eran Message-ID: <55FE8C06.8010504@mellanox.com> Date: Sun, 20 Sep 2015 13:35:50 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150915034549.GA27847@obsidianresearch.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.0.52.254] X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;AM1FFO11OLC006;1:wzWYTTaxW4fOlxF5nvfOvgWd+svCAsTRwcQiS7D+5XeBGJ7tG/Of+trM/G2D05dtRcpoiKiS2X3fvf1crDSPDpsltZTY+yYGO8zOAbqvKfvCSPRGPXz/F29AGR7H1rIrSYQ64iuvBtbz77xUxybg3s98ptCQqm8Jq1Ra/b7suGyJIi57CF2xSEHF+ctwcXtQWl/KjaxH0s6OZwlTXX4iTp3zOsKtPNld+FaOaD2bX4xfzUWi5bK0MqyHF2OzC5xm7qRCQBEQ497baxKqHNchbhrYPws9y9dr0YovR81f56yN51lv+weElkV+0sAsp/KYLXXDnZHJM26PKRjcFsX0PVd5HgxDlADynKdD21Y3iU3IWY9F1xS58xoapmJZdxSPbKnPN0zcvsDCHGS+xFxf1w== X-Forefront-Antispam-Report: CIP:193.47.165.134;CTRY:IL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(438002)(24454002)(199003)(189002)(479174004)(106466001)(87936001)(87266999)(54356999)(50986999)(76176999)(65816999)(80316001)(6806004)(33656002)(64126003)(86362001)(11100500001)(93886004)(59896002)(2950100001)(92566002)(50466002)(77156002)(62966003)(36756003)(64706001)(65806001)(68736005)(65956001)(77096005)(47776003)(46102003)(5001860100001)(5001830100001)(5001770100001)(83506001)(23746002)(5004730100002)(189998001)(4001350100001)(4001540100001)(97736004)(3940600001);DIR:OUT;SFP:1101;SCL:1;SRVR:AMSPR05MB360;H:mtlcas13.mtl.com;FPR:;SPF:Pass;PTR:ErrorRetry;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;AMSPR05MB360;2:TAixtlv9s2Ww+CLlA3iB5Ipf0dSX+b1OFEyjg5LAzgxJGmpdbvFfpPAOG3MuqEQXq0669v/cXT5Nmz5NelvuwBHhlTtyvSOOqjfd3huwiQjNZxdyQc93brfSdrTiek2AkoZYRYajUEOFV9+OY5hZGx/MPod9Fy0NsxVf4XGY+zM=;3:W2uesbUVkwx4DqEb3MjB1vdKiYAwy/os8Ns3jSeS10maDsI5Pn0gmlAikvACsQYJ9JOzEJsTIDspL4JtnEGTDDwHKThQTkY49vp+nJB/E/uGIiNJU85IWyywWhoUrLrTjmFQHPzZd1dSwcEh0f92uM/dKvrPxzW4DGyrEfbt6pe4p5lVAv8jUPlmi8n2ZYFCgqTIhUqi/qDtOBPqsNkG1FZnNQlZ5lXSGR90uQrnPRtIUApl7cAn847F2RDULgJ+flXDMRTAQEB3yhQBmzIncA==;25:b9mB3jkcGr3DfpVYsh4RGyK/IKheZBe7dxiiTHYED1HfuIffc9gwVt65wBz+iqqU9mkbw8YNY6XfCjmvlg70HLdB6uXRByzi9bGBWdr6J00YV+RgEFOU2lT7tnmsg2qGKRSR/mCF9siOkl5w8ANRMIbe5SAAqTAxjeyQiuh02sHQ3o6trEGKsAjAsr4PwP6TVCW12CGsuGhTUVNvAZYz4apziC3O7CjdDuaBPSwtq/Yczk11BdyKGOHtHFRhqwCV9V2L5C8ePV65dZ+qYtyO6A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(8251501001);SRVR:AMSPR05MB360; X-Microsoft-Exchange-Diagnostics: 1;AMSPR05MB360;20:n+LggV/pWZ+NiC2BNA45LN6jkOiURQ12ckp+Gxw9451xQi0qfKdPVwPT8xsX+7UFA1abgOHb9+FTrReEUtYrVLRah/OlMjtrb/qZjJSJSyl5Cx1grGRxT9mle0qZTL4fNaJD4PuzixXHISVoRt6p3fa23eTsuES6+GQmiJTfK+T7HN7SgLO852oYmkfGlIZhNXpFJPMZ3sTbh2YmsYBcIVN9xZ1SdHhOp+AYe+I7ovuo6rGnW5aBzdvqJl6TxfE/WdM7ROIm1JXWpfhNiZH9d+jgfTwYB4nhlhii2qdbsR8E+2TWaHpfYCCSdxtAZ7BCHn4Akpud2oo0mQ/WoEqGoSXBQR/Zpe47p+5qmdse+PDw5UL7kEVXAnm9WfekM0yPvxYF5aWE5wSyAG5M4fyFxjzX88O7Jo63/aCjSiDyHDzfPuD29wColhDcdvVodFosT5N6Ti+iknFSfJsu07cbRrZg5dlO/1aDHq5L8Ubo9WAbFtMmUIRZEQPXN1OE0zjN;4:K7xUZEOYmFh5jaYAP+t2BFDF7bbgg/YhFf3INE+iTZBDSJ+kW5UbhgcUsZaXajBipu2vCoAMmP+Ko6VYEcwVnsen4nt//QMeS16WK3i/Kck9wmLNncjs/Bd6RYNRTHBJxrL+5ursCSPdol/F5iaFSNi1LnmnoDX0qVTGMNFhkLgWHqCtDDTmDewdCUNhz0RSOojEphm8+1rIsuXNTKaoFb5eO+ivqM/Hw3xGMFL4oM9/1Y7R2u8LX6i93450kyFl X-Exchange-Antispam-Report-CFA: BCL:0;PCL:0;RULEID:;SRVR:AMSPR05MB360;BCL:0;PCL:0;RULEID:;SRVR:AMSPR05MB360; X-Forefront-PRVS: 0705EB1700 X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;AMSPR05MB360;23:AHEo92KqcR0bKW2CBfe150Q4kZDCFlMnTY7+U4?= =?Windows-1252?Q?wPYetrt2xKqKWLy4a7LLi0OBBDIJRi5QpYWC+GplLTbMPfPWJcW4g1ij?= =?Windows-1252?Q?X9HQ9BWJM8RgD/DaBgq/JO6jh85SABuQX7fHDhpVK+JwgeGvTbFXiCGr?= =?Windows-1252?Q?O4w264E52bn1U3Yzg+IAIOaKRq94cYONRUfyMJCHZjd9dZCVze5WptMz?= =?Windows-1252?Q?cuAVeKrzv1Suky5XYs5TIyzqa/5K0KOHE3D3JzACphFbnpU9j2rMLRS8?= =?Windows-1252?Q?HmqZ4j+Q363LpYOGt259GXHGY92xdwoRi4zHQvSIbn+WlFkqVT9uo8C8?= =?Windows-1252?Q?hm/lDTVqqhA4KpIn/jXKXInjpuqiWtvtwBIUlXZRmGhleMxdnuAZOlcg?= =?Windows-1252?Q?Q8dYyikafXkg8RvKB67XX1021aLweI87G64HuB0rR2whyNrNgJVx9Gz8?= =?Windows-1252?Q?a9xY6ZmK07NU0EBWrszJsoZKJrBatqtoISfnVKHWWg2biqdYQOpUv8sA?= =?Windows-1252?Q?2PjXCUjJdlt4MVvYylul+XvNf2c2CbEIvQF3V0YIA6kbPNH1gvbHEU64?= =?Windows-1252?Q?RiLeY8cT/YbTRFvCJnRkAEPgaNsnauTlD+F7U5YVOp2AWAv5wz5FYKI5?= =?Windows-1252?Q?NbmIqnzOikymW35s5mco8P2FfX0d5meaeQpF2/xoVd/XYnJxqUkp/Aul?= =?Windows-1252?Q?YWKSoTHaiL5royAhbPoIgLWhxlQA0Cf/spHU1v7FIBgHfF+DxkghZLXL?= =?Windows-1252?Q?6jIjU/mdvuzNSvG0Ykm+VOD0G8YNXLBJpL+sRLesUbOymHLBDQbvacj6?= =?Windows-1252?Q?apag7/LUjoHiXiMN0159YT8PBz7MVkL1W627LrvOwY3CsbhwPqBN/smD?= =?Windows-1252?Q?j7uf3XBUicmN65luOBDdQZLBU7HUzPctsx3JTbjU04GC24vus0VCTq++?= =?Windows-1252?Q?HqAIqg7/LK5oP2MxKEy8sVceAS3zqgD81FpQkc3ml37oEWTZs3L7xl2K?= =?Windows-1252?Q?i6XTpX7xyi7+wCyVOutNn4Jn6jufPbA2LAe21kRKj8VCFruXIapCztpK?= =?Windows-1252?Q?rHUL91mF07TMrU9AyBtfIpwvtIU4gPE3zeQqLroDTu6DHJZAG02RwuRB?= =?Windows-1252?Q?USaabRL7lOxPGk7FMV2n8HZtzh1+ck7wuwZUVdmyM8HrDEpmfbkH/GLb?= =?Windows-1252?Q?Lo4amXXNu2LuwKeXOZuDNBE+pVJqerGKmGOopnWcmLycYuEi0vIAJOJQ?= =?Windows-1252?Q?QrD3Tqojw4PWNfIAvi5HuZSjMSEatLmAp4k+DXv5au60qJNCd+1aeezq?= =?Windows-1252?Q?a1Hz2ZFoyjUn+c6YbYqImi2A=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;AMSPR05MB360;5:qRV7qbJ6dkt2JllJ9nUT42MXBG1QmR5c0W/bTjDUMMt0mFgjKVP4KNLYE50BgmH+ayR8ESeJSkCRazrX4SbyWJ+9g8lqnQ6gzmrOvxrwcE87Y+SZT1G/6kU8qB6egiDZ8ua7WdJ1qFCu2Ev+ao5HHg==;24:DxUIyiKlNmQIvP5AQTyawde88GH2QHGd9jDKIXMiDWhx5BKxP5GpnPj624+sL0Rg4I5e5rnqXA3+PX8lD8qmtfbQgw3irS7MROSUoOPyOyo=;20:gL2tKmh2x3PYxV/2XoIlOeTJzfGy6PitgQdgZS+nIw5oseJN8huXTUDeTYT0Gm76vIXlenWTs33dPmJbQ1SZJA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2015 10:35:32.9210 (UTC) X-MS-Exchange-CrossTenant-Id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=a652971c-7d2e-4d9b-a6a4-d149256f461b;Ip=[193.47.165.134];Helo=[mtlcas13.mtl.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR05MB360 X-Microsoft-Exchange-Diagnostics: 1;AMSPR05MB520;2:LfX9vHXDNOvQXOBMUyMFHhNpZOgAQ8F3pMkWaQVKZCPNmLw+k9hGReqaxweeeC9q4qjlHfqiaBUHJ5KOwOvuucWO2OvfKjz+70MfYNsL0JF85m7ml9ZgVjIIcrh06Du3clvEJ0+Ekhg1z0JoJvU/4Xogtt5BQsbJ/dlGTxp8cYE=;23:B/lYlOXcf8+ZNHY4atCWKWWAyQjdXvq5aKADdlTRTzJ99Q+9KQYv59MCyTB6lYkxOmO1CdNjbCZhbN2tZKu8xfkOfCuyp74sWfhi1fW0OS20ykzh54A3IMSwUL86ELHnOBioDKluRmdWdyMIAzLi925Qaf6cNGqaBZnd1dfUupWYNkC9r51QBL3r2rnIXb1i X-OriginatorOrg: Mellanox.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/09/2015 06:45, Jason Gunthorpe wrote: > No, I'm saying the resource pool is *well defined* and *fixed* by each > hardware. > > The only question is how do we expose the N resource limits, the list > of which is totally vendor specific. I don't see why you say the limits are vendor specific. It is true that different RDMA devices have different implementations and capabilities, but they all use the expose the same set of RDMA objects with their limitations. Whether those limitations come from hardware limitations, from the driver, or just because the address space is limited, they can still be exhausted. > Yes, using a % scheme fixes the ratios, 1% is going to be a certain > number of PD's, QP's, MRs, CQ's, etc at a ratio fixed by the driver > configuration. That is the trade off for API simplicity. > > > Yes, this results in some resources being over provisioned. I agree that such a scheme will be easy to configure, but I don't think it can work well in all situations. Imagine you want to let one container use almost all RC QPs as you want it to connect to the entire cluster through RC. Other containers can still use a single datagram QP to connect to the entire cluster, but they would require many address handles. If you force a fixed ratio of resources given to each container it would be hard to describe such a partitioning. I think it would be better to expose different controls for the different RDMA resources. Regards, Haggai From mboxrd@z Thu Jan 1 00:00:00 1970 From: Haggai Eran Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource Date: Sun, 20 Sep 2015 13:35:50 +0300 Message-ID: <55FE8C06.8010504@mellanox.com> References: <55F25781.20308@redhat.com> <20150911145213.GQ8114@mtj.duckdns.org> <1828884A29C6694DAF28B7E6B8A82373A903A586@ORSMSX109.amr.corp.intel.com> <20150911194311.GA18755@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373A903A5DB@ORSMSX109.amr.corp.intel.com> <20150914172832.GA21652@obsidianresearch.com> <20150914201840.GA8764@obsidianresearch.com> <20150915034549.GA27847@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150915034549.GA27847-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jason Gunthorpe , Parav Pandit Cc: "Hefty, Sean" , Tejun Heo , Doug Ledford , "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" , Johannes Weiner , Jonathan Corbet , "james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org" , "serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org" , Or Gerlitz , Matan Barak , "raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org" , "akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org" , "linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-rdma@vger.kernel.org On 15/09/2015 06:45, Jason Gunthorpe wrote: > No, I'm saying the resource pool is *well defined* and *fixed* by each > hardware. > > The only question is how do we expose the N resource limits, the list > of which is totally vendor specific. I don't see why you say the limits are vendor specific. It is true that different RDMA devices have different implementations and capabilities, but they all use the expose the same set of RDMA objects with their limitations. Whether those limitations come from hardware limitations, from the driver, or just because the address space is limited, they can still be exhausted. > Yes, using a % scheme fixes the ratios, 1% is going to be a certain > number of PD's, QP's, MRs, CQ's, etc at a ratio fixed by the driver > configuration. That is the trade off for API simplicity. > > > Yes, this results in some resources being over provisioned. I agree that such a scheme will be easy to configure, but I don't think it can work well in all situations. Imagine you want to let one container use almost all RC QPs as you want it to connect to the entire cluster through RC. Other containers can still use a single datagram QP to connect to the entire cluster, but they would require many address handles. If you force a fixed ratio of resources given to each container it would be hard to describe such a partitioning. I think it would be better to expose different controls for the different RDMA resources. Regards, Haggai