On Fri, Jan 8, 2016 at 1:36 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Fri, Jan 08, 2016 at 01:31:06AM +0530, Parav Pandit wrote: >> > What I was >> > trying to say was that unless the number is extremely high, it'd be >> > far simpler to hard code them in the rdma controller and let drivers >> > enable the ones which apply to them. >> >> Instead of in rdma controller, its hard coded in IB stack. >> I see this as an advantage where resource definition ownership remains >> with IB stack maintainers, rather than rdma cgroup maintainer. >> rdma cgroup maintainer doesn't have to understand what SRQ vs QP or >> ODP type MR or multicast group is. >> IB stack maintainer is better placed to judge and define it. >> >> I would like to hear from Jason, Doug, Liran and other RDMA experts >> about their thoughts. > > That's fine. Make it a header file in IB stack which is included from > the rdma cgroup controller. The only things are not building a huge > dynamic framework for something which can easily be a simple static > thing and having some oversight in adding resource types. > o.k. That doable. I want to make sure that we are on same page on below design. rpool (which will contain static array based on header file ) would be still there, because resource limits are on per device basis. Number of devices are variable and dynamically appear. Therefore rdma_cg will have the list of rpool attached to it. Do you agree? > Thanks. > > -- > tejun -- 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
