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. Yes, using a % scheme fixes the ratios, 1% is going to be a certain number of PD's, QP's, MRs, CQ's, etc at a ratio fixed by the driver configuration. That is the trade off for API simplicity. Yes, this results in some resources being over provisioned. I have no idea if that is usable for the workloads people want to run.. But *there is no middle option*. Either each and every single hardware limited resources has a dedicated per-container limit, or they are *somehow* bundled and the ratios become fixed. If Tejun says we can't have something so emphemeral as a vendor specific list of hardware resource pools - then what choice is left? > Instead of bringing such complex solution, that affecting all the > layers which solves the same problem as this patch, > its better to keep definition of "bundle" in the user > library/application deployment engine. > where bundle is set of those resources. The kernel has to do the restriction, so at some point you are telling the kernel to limit each and every unique resource the HW has, which is back to the original patch set, munging how the data is passed makes no difference to the basic objection, IMHO. > 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
