Hi Tejun, On Fri, Nov 11, 2016 at 12:53 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, Parav. > > On Thu, Nov 10, 2016 at 11:26:28PM +0530, Parav Pandit wrote: >> > That looks great to me from cgroup side. Do you have plans for >> > exposing the maximum numbers available? >> >> If I have to expose max limits, I need new file interface as rdma.limit. >> Because once rdma.max is set, user space cannot get back the old value. >> It needs to cache it. user space tools might have been restarted and >> so on, so store in other file etc. >> So such user space solutions are just ugly. >> >> Getting and setting values in device agnostic way, through cgroup >> files is desirable, however its not must. It can fallback on using >> verb based API. >> >> So if there is no objection, I prefer to have rdma.limit file as >> incremental patch once base version is merged. > > How about something like RESOURCE.available field in rdma.stat file? > Its value can be what's maximally available at that level when max is > unlimited and there is no competition. At top level cgroups, it'd be > the total resources available in the system. At sub levels, it'd be > min of what's available to the grandparent and parent's limit on the > resource. > > This would be in line with cgroup conventions and would behave the > same way nested making things easier for containers. > Yes. This is what is needed. Awesome. I will include in follow on patch after first round of functionality. Patch_v13 will have base functionality similar to v12. This new file will be once code is merged. > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
