Re: [PATCH v1 04/14] xprtrdma: Use ib_device pointer safely

[Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>]

On May 11, 2015, at 2:26 PM, Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

>>> ia->ri_device is never updated. The only place it is set is in
>>> rpcrdma_ia_open().
>> 
>> So you assume that each ri_id that you will recreate contains the
>> same device handle?
>> 
>> I think that for ADDR_CHANGE event when the slave belongs to another
>> device you will hit a mismatch. CC'ing Sean for more info...
> 
> I'm not familiar with the xprtrdma code.  From the perspective of the rdma_cm, if a listen is associated with a specific IP address, then it will also be associated with a specific device.  If an address change occurs, and the address moves to another device, then the app is essentially left with an unusable listen.  Received connection requests will not find a matching listen and be dropped.

Thanks Sean.

xprtrdma is the client-side (initiator), so it drives transport connects. The
server-side (target) does the listens. My proposed change is only on the client.

> If the address moves ports on the same device, then I think this works out fine in the case where the app ignores the ADDR_CHANGE event.

xprtrdma currently doesn’t explicitly handle ADDR_CHANGE events (and neither
does the server-side, looks like).

In the deployment scenarios I’m aware of, a single HCA with two ports is
used to form the bonded pair. I’m sure that’s not the only way this can
be done, though.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html