From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932669AbcFCK40 (ORCPT ); Fri, 3 Jun 2016 06:56:26 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:33056 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752754AbcFCK4X (ORCPT ); Fri, 3 Jun 2016 06:56:23 -0400 MIME-Version: 1.0 From: Parav Pandit Date: Fri, 3 Jun 2016 16:26:21 +0530 Message-ID: Subject: Re: [PATCHv10 1/3] rdmacg: Added rdma cgroup controller To: Christoph Hellwig Cc: Tejun Heo , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , linux-rdma@vger.kernel.org, lizefan@huawei.com, Johannes Weiner , Doug Ledford , Liran Liss , "Hefty, Sean" , Jason Gunthorpe , Haggai Eran , Jonathan Corbet , james.l.morris@oracle.com, serge@hallyn.com, Or Gerlitz , Matan Barak , 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 Christoph, Reopening thread for discussion so that I can proceed to generate next patch. Recap: rdma cgroup controller in the patch defines the framework so that RDMA subsystem can define the resources. This is similar to at least two functionality provided by core kernel. (a) Block elevator defining framework and provides way to loadable kernel modules to define actual IO scheduler (out of the 3 or 4) that can be plugged-in since last many years. (b) VFS core defining framework for external loadable modules to load file system. None of these core kernel functionality actually filter based on enum or names - which IO scheduler(s), file system(s) are allowed/disallowed. rdma cgroup controller and rdma subsystem follows similar design approach. Therefore can I go ahead with current approach? Tejun also mentioned that he likes to see rdma resources to be defined by rdma cgroup rather than rdma subsystem in below thread primarily to reduce the complexity. https://lkml.org/lkml/2016/4/4/507 However submitted patch is fairly small for defining resource in rdma subsystem (instead of kernel). This also allows to provide fixes and features done in rdma subsystem in field at much faster pace and avoids complexity around back-porting on various OS and their kernel flavors. Please let me know your views. Regards, Parav Pandit On Tue, Apr 19, 2016 at 2:26 PM, Parav Pandit wrote: > Hi Christoph, > > I was on travel. Sorry for the late inline response and question. > > Parav > > > > On Tue, Apr 5, 2016 at 10:57 PM, Christoph Hellwig wrote: >> On Tue, Apr 05, 2016 at 05:55:26AM -0700, Parav Pandit wrote: >>> Just because we add one more rdma resource, we need to ask someone to >>> upgrade kernel? >> >> Yes. Just like when you need any other core kernel resource. > > By architecture Linux kernel allows > (a) plugin of any new block level IO scheduler as kernel module. > This is much more fundamental resource or functionality than rdma resource. > (b) plugin of any new file system as kernel module. > > Changing both in field and out of box can do be more harmful than > defining new rdma resource. > > RDMA Resource definition by IB core module is very similar to above > two functionality, where elevator and VFS provides basic support > framework and so rdma cgroup controller here. > > So can you please help me understand - which resource did you compare > against in your above comment for "core kernel resource"? > I compared it with similar functionality, flexibility given by (a) > block IO Scheduler and (b) VFS subsystem to implement them as kernel > module.