[openib-general] Re: [RFC] change to ib_create_cm_id()

[Sean Hefty]

Michael S. Tsirkin wrote:
>>The proposal is to change the cm_id's so that they become associated with a 
>>specific device.  Currently, they are not visibly associated with a device.
> 
> I understand. But you said "this will help prevent the CM from returning
> a cm_id associated with a device" which seems to correspond to
> the existing API.

Currently the CM returns a pointer to the device that a REQ or SIDR REQ is 
received on.  This assists the user in allocating the QP used with the connection.

> I was asking to keep the API that listens on all devices
> for listeners, and require the device on active side only.

Unfortunately, the problem is with listens.  On the active side, the cm_id is 
implicitly bound to a device through the associated QP.

> Thats what I was trying to say: e.g. for SDP, when a device is
> added, we need to scan all listening connections and add a new cm id
> for the device that is being added.

Why do you need to scan all listening connections when a new device is added?

> When a device is being removed, again scan all listening connections
> and remove the cm id for the device that is being removed.

Assuming that you have some sort of per device context, couldn't you just store 
the cm_id's with that structure?  This would avoid any scans.  As an aside, 
device removal should be uncommon, so I don't see efficiency as a high priority.

> So, I guess, I'll just have to add a list of active cm ids, per device.
> I would have to allocate chunk of memory and keep
> a cm id, and sdp connection and the list head on each. Ugh.
> Currently cm handles this fine for the listening side.

Without changes to the CM API, the device pointer returned in a REQ may be 
invalid.  This pushes validation of the pointer up to the ULP which would need 
to be verified for every connection.

- Sean