> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > > > What is really missing here I guess is a mechanism that would > > enforce containers to only use certain pkeys - perhaps with > > something like an RDMA cgroup. It could force containers to only > > use approved pkeys not only with RDMA CM, but through uverbs, and > > other user-space interfaces. > > Ideally yes. Without that it just means you can't use pkey > meaningfully with containers.. >
That's why partition enforcement should be separated from namespaces. If you want to restrict a container to a specific set of pkeys, use cgroups. This would apply both to CM MADs and QPs. - In the MAD case, CM MADs would be first matched to a namespace and rdma_id and dropped upon pkey conflict (with either the headers or the payload). - In the QP case, modify_qp() would fail on conflict. Partitioning needs to be enforced also for applications that don't use the CM at all... For namespaces, it seems more natural to lookup the namespace based solely on the CM payload. After all, it is the payload that designates the entity that you want to establish a connection to, rather than the packet headers, which are just meant to relay the packet to the proper CM agent. (Spec-wise, it is even possible to use completely different node to open a connection on behalf of another node.) So, the sole role of pkeys in the context of namespaces is to locate the proper namespace; not for partition isolation. So, as a first step, let's get the namespace lookup in place. Next, add an rdma crgoup, which would control pkeys, as well as resource counts (you don't want one container to rob the whole system from all QPs...). > Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
