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

[Michael S. Tsirkin]

Quoting r. Sean Hefty <mshefty at ichips.intel.com>:
> Subject: Re: [RFC] change to ib_create_cm_id()
> 
> Michael S. Tsirkin wrote:
> >>This will bind all cm_id's to a specific device, including cm_id's 
> >>associated with listens.  This will help prevent the CM from returning a 
> >>cm_id associated with a device that a consumer may have already seen as 
> >>removed.
> >
> >Looking at the API, cm_ids are not currently associated with a specific 
> >device.
> >What am I missing?
> 
> 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.

> >So, I gather a ULP would need a list of cm_ids per connection, scanning
> >all of them on each cm operation, scanning and updating
> >these lists in all listening connections on each hotplug event.
> 
> I'm not following you here.

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

> The change affects listeners the most.  Instead of calling listen once, it 
> would need to be called once for each device.  Since most clients have per 
> device context, the listen cm_id would need to move from a single global 
> structure into the per device structures maintained by the client.
> 
> - Sean
> 

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.
When a device is being removed, again scan all listening connections
and remove the cm id for the device that is being removed.

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.

-- 
MST