Hi Tejun, On Wed, Oct 19, 2016 at 8:03 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Wed, Oct 19, 2016 at 03:04:52PM +0530, Parav Pandit wrote: >> > Heh, we can go for per-mil and use %0 as the suffix if absolutely >> > necessary but is this a real issue? >> >> We need to provide current version to exceed the 100 containers limit first. :-) >> Please let me know if such user interface already exist as reference point. >> I prefer to avoid introducing such configuration. > > We don't have such usage yet. rdmacg would be the first one doing > something like this. > >> > I think it's a lot more consistent to implement all absoulte limits >> > through max. >> >> I agree. I will implement reporting actual max values instead of >> reporting "max" string so that percentage configuration can be done by >> the user space tools. >> (post merging of v12). >> Waiting for direction from Doug. > > That doesn't sound like a good idea. What happens when the amount of > available resources changes either through underlying resource changes To my knowledge device configuration cannot change on the fly while its still active. PCIe SR-IOV VF might be able to do so. In that case we might need to introduce event notifier framework. This can be possibility regardless of percentage configuration if such device comes up. However this appears far fetched. > or config changes in one of the ancestors? What "max" means is "no > limit is imposed" which is different from "limit it to 100% of what's > currently available". Charging is hierarchical for rdmacg too. rdma.max configuration exist at all the levels so ancestors change won't affect its children. rdma.max absolute (or future percentage) value is with reference to the total device resources. > 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
