On Thu, Oct 20, 2016 at 01:48:27AM +0530, Parav Pandit wrote: > On Thu, Oct 20, 2016 at 1:35 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > > Hello, Parav. > > > > On Thu, Oct 20, 2016 at 01:24:42AM +0530, Parav Pandit wrote: > >> userland can get the max numbers using other framework which is used > >> by control & data plane available in C library form or in form of > >> system tools. > >> I was preferring to get and set through same interface because, > >> It simplifies user land software which is often not written in C so > >> its likely that it needs to rely on system tools and parse the > >> content, iterate through devices etc. > >> Getting these info through rdma.max just makes it simple. There will > >> be logic built to read/write rdma.max in userland anyway, which can be > >> leveraged for percentage calculation instead of doing it from two > >> places. > > > > Yeah, I get that this can be convenient in this case but it isn't a > > generic approach. I'd much prefer keeping it in line with other > > resources. > > > Hmm. we don't have /proc/sys/kernel/pid_max type of simple interface > to get the max values for rdma resources. > rdma.max is close to that simplicity. Sorry for my late response (very long weekends and piles of mails after it) and for not clarifying our requirements better, which are very simple. 1. We will have vendor specific vendors objects in the future (new ABI support it and designed for that). 2. We don't want to fight for every addition of such objects to cgroup list. 3. We don't want to teach and/or rewrite scripts for "average" user after addition of new objects. 4. Cgroup configuration should be as close as possible to "standard" if such exists, so all infinite internet guides will work for RDMA too. From my understanding of current status. My naive approach of introducing GLOBAL_HCA object is the way to go and the real question is to understand how to configure it, am I right? > > > > > > Thanks. > > > > -- > > tejun
Attachment:
signature.asc
Description: PGP signature
