RE: [PATCH v3 for-next 05/13] IB/cm: Reference count ib_cm_ids

Hefty, Sean
2015-05-19T22:52:59Z

> I find Haggai's argument compelling, it is a very small amount of code
> and data to add a sharing count, and a very large amount to duplicate
> the whole service id map into cma.c.

I get wanting to share the listen list, but we end up with this:

> drivers/infiniband/core/cm.c | 129 +++++-

that's more code than what the ib_cm module uses to track listens, and the result is a solution that ends up being split in a weird fashion between the ib_cm, iw_cm (TBD), and rdma_cm.

I wonder if the existing ib_cm interface is even what we want. Currently, the rdma_cm pushes the private data (i.e. IP address) comparison into the ib_cm. This is only used by the rdma_cm. Should that instead be moved out of the ib_cm and handled in the rdma_cm? And then update the ib_cm to support multiple listens on the same service id.

For example, the ib_cm could simply queue all listen requests on the same service id. When a REQ arrives, it just calls each listener back until one 'claims' the REQ. The destruction of a listener could then be synced with the callback. From what I can tell, the current proposal requires that the ib_cm user be prepared to receive a REQ callback for a listen that it has already destroyed. If needed, a flag can be added to the ib_cm_listen to indicate if the service id is shared/exclusive.

- Sean