From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752076AbbIPElH (ORCPT ); Wed, 16 Sep 2015 00:41:07 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:37401 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751708AbbIPElE (ORCPT ); Wed, 16 Sep 2015 00:41:04 -0400 MIME-Version: 1.0 In-Reply-To: <20150915034549.GA27847@obsidianresearch.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> Date: Wed, 16 Sep 2015 10:11:01 +0530 Message-ID: Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource From: Parav Pandit To: Jason Gunthorpe 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" , Haggai Eran , Or Gerlitz , Matan Barak , "raindel@mellanox.com" , "akpm@linux-foundation.org" , "linux-security-module@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jason, Sean, Tejun, I am in process of defining new approach, design based on the feedback given here for new RDMA cgroup from all of you. I have also collected feedback from Liran yesterday and ORNL folks too. Soon I will post the new approach, high level APIs and functionality for review before submitting actual implementation. Regards, Parav Pandit On Tue, Sep 15, 2015 at 9:15 AM, Jason Gunthorpe wrote: > On Tue, Sep 15, 2015 at 08:38:54AM +0530, Parav Pandit wrote: > >> As you precisely described, about wild ratio, >> we are asking vendor driver (bottom most layer) to statically define >> what the resource pool is, without telling him which application are >> we going to run to use those pool. >> Therefore vendor layer cannot ever define "right" resource pool. > > 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. > >> rdma cgroup will allow us to run post 512 or 1024 containers without >> using PCIe SR-IOV, without creating any vendor specific resource >> pools. > > If you ignore any vendor specific resource limits then you've just > left open a hole, a wayward container can exhaust all others - so what > was the point of doing all this work? > > Jason From mboxrd@z Thu Jan 1 00:00:00 1970 From: Parav Pandit Subject: Re: [PATCH 0/7] devcg: device cgroup extension for rdma resource Date: Wed, 16 Sep 2015 10:11:01 +0530 Message-ID: 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=UTF-8 Return-path: In-Reply-To: <20150915034549.GA27847-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jason Gunthorpe 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" , Haggai Eran , 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 Hi Jason, Sean, Tejun, I am in process of defining new approach, design based on the feedback given here for new RDMA cgroup from all of you. I have also collected feedback from Liran yesterday and ORNL folks too. Soon I will post the new approach, high level APIs and functionality for review before submitting actual implementation. Regards, Parav Pandit On Tue, Sep 15, 2015 at 9:15 AM, Jason Gunthorpe wrote: > On Tue, Sep 15, 2015 at 08:38:54AM +0530, Parav Pandit wrote: > >> As you precisely described, about wild ratio, >> we are asking vendor driver (bottom most layer) to statically define >> what the resource pool is, without telling him which application are >> we going to run to use those pool. >> Therefore vendor layer cannot ever define "right" resource pool. > > 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. > >> rdma cgroup will allow us to run post 512 or 1024 containers without >> using PCIe SR-IOV, without creating any vendor specific resource >> pools. > > If you ignore any vendor specific resource limits then you've just > left open a hole, a wayward container can exhaust all others - so what > was the point of doing all this work? > > Jason