[ofa-general] RE: [RFC v2 PATCH 3/5] rdma/cma: add high availability mode attribute to IDs

[Sean Hefty]

>I am fine with the approach of always report the event and let ULPs
>ignore it. Looking on how the ABI versions are exchanged between the
>rdma_ucm module to librdmacm,  I don't see much alternatives other to
>bumping the ABI version to five. If librdmacm can somehow note against
>what ABI version the app was built, we could bump the ABI version to
>five and require the user to upgrade his librdmacm to be able to run,
>but have --librdmacm-- hide this event from the user in case "his
>version" of the ABI is smaller.

I was only thinking of the kernel interfaces, but I don't see that this really
changes the ABI.  An existing library continues to work unmodified.  (Is this
that different than adding a new return value from a call?)  If there really is
an issue, then the rdma_ucm can toss the event.

>I would like to look into this possibility which as you stated later in
>your post is simpler compared to the alternatives and would also make
>the current code of supporting device removal less complex. So
>can/should that mutex be the existing one defined in cma.c or a new one?

After more thought, this approach is what I would try first.  I think you will
need a new mutex per rdma_cm_id that does nothing but serializes callbacks.  You
might be able to acquire/release it in disable/enable remove, but I didn't look
into the implementation in that much detail.

- Sean