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 <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
