On Sun, Nov 19, 2017 at 08:43:16AM +0200, Alex Rosenbaum wrote: > This new ibv_alloc_td() returns a ibv_td (Thread Domain), and it only > manages the Thread related information Yes, sorry, my bad. I didn't read this carefully, you are right, it is this the API I was thinking about: > The new ibv_alloc_parent_domain() returns a ibv_pd. > https://www.spinics.net/lists/linux-rdma/msg56891.html So I'd like to see: struct ibv_parent_domain_init_attr { - struct ibv_pd *pd; /* referance to a protection domain, or NULL */ + struct ibv_pd *pd; /* referance to a protection domain, can not be NULL */ > > So, all TD's have to be created from a PD, and the concept of a TD > > without a PD should be entirely removed from the API. > > I can definitely see an application that wants to do something smart > with it's CQ's, like per thread or NUMA aware logic. While it has many > QPs' which it can't commit to any thread logic. > Here we'll force the user to provide some protection domain while > creating the CQ's with specific TD's. It doesn't have to be so. When we revise the CQ api it can directly accept a TD object, so there is no need for it to use the 'parent domain' version of the PD. And even if we did use the PD for consistency, it doesn't hurt at all to pass in a PD&TD to the CQ object and then have the CQ ignore the PD portion. Jason -- 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
