> Because actual hardware resources *ARE* the limit. We cannot abstract > it away. The hardware/driver has real, fixed, immutable limits. No API > abstraction can possibly change that. > > The limits are such there *IS NO* API boundary that can bundle them > into something simpler. There will always be apps that require wildly > different ratios of the basic verbs resources (PD/QP/CQ/AH/MR) > > Either we control each and every vendor's limited resource directly > (which is where you started), or we just roll them up into a 'all > resource' bundle and control them indirectly. There just isn't a > mythical third 'better API' choice with the hardware we have today. > 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. If we try to fix defining "right" resource pool, we will have to come up with API to modify/tune individual element of the pool. Once we bring that complexity, it becomes what is proposed in this pachset. 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. May be instead of having invidividual files for each resource, at user interface level, we can have rdma.bundle file. this bundle cgroup file defines these resources such as "ah 100 mr 100 qp 10" > So? I don't think it is really important to have an exact, precise, > limit. The HW pools are pretty big, unless you plan to run tens of > thousands of containers eacg with tiny RDMA limits, it is fine to talk > in broader terms (ie 10% of all HW limited resource) which is totally > adaquate to hard-prevent run away or exhaustion scenarios. > rdma cgroup will allow us to run post 512 or 1024 containers without using PCIe SR-IOV, without creating any vendor specific resource pools. > 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
