On 5/11/2015 9:26 PM, Hefty, Sean 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.
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.
It might be saner to construct a virtual ib_device in this
case that consumers can depend on.
I'm not sure how does a virtual ib_device can work - that goes
to the verbs themselves... Seems like a layering mis-match to me...
I interpreted Chuck as asking for some lower-level way of handling this, so that all ULPs don't need to re-implement this.
It's not really a re-implementation, address resolution attaches the
the ib device. The assumption that for the same address the same ib
device will be attached is wrong for bonding over more than one device.
It's just something that rdma_cm user needs to be aware of if/when
trying to cache the device handle.
I agree that this would be hard (impossible?) without ULPs operating at a slightly higher level of abstraction.
Maybe the rdma_cm could be extended for this purpose, for example, by exposing its own devices, which either map directly to a verbs device, or handle a virtual mapping.
I guess it can be done, but it will require port all the ULPs to
use some sort of abstraction layer. Something that I'm not very
enthusiastic about...
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
