Sean Hefty wrote:
+static int cma_netdev_callback(struct notifier_block *self, unsigned long
event, void *ctx)
+
+ mutex_lock(&lock);
+ list_for_each_entry(cma_dev, &dev_list, list)
It seems like we just need to find the cma_dev that has the current mapping
If your comment comes to say that maybe first find the cma_dev to which
this event applies, I don't think its possible, see below. If I didn't
get you right, can you please explain it a little more.
The rdma-cm maintains a mapping between IDs to the physical devices. The
mapping is established during address resolution using the HW address of
the --network-- device that was resolved (eg through ARP and then
looking on neigh->dev or route lookup) for this ID.
In the bonding case, the network device --borrows-- the HW address from
the active slave device. During fail-over, the bonding net device
changes its HW address and then the netdev event is delivered on which
this code acts. So the same cma_dev can have IDs with different netdev
HW address in their dev_addr struct, say bond0 = <ib0, ib1> and pdevA
list = { <ID1, HW(ib0)>, <ID2, HW(ib1)>} depending on the time address
resolution was done to ID1,ID2 and the ULP behavior on the ADDR_CHANGE
event. I don't see how to get along with a simple check that tell on
what cma_dev to look for matches. If we really want to avoid scanning
all the cma_dev list, we can add a mapping between --net devices-- to
IDs and then scan only the list of the affiliated netdevice.
So I am still left with the general rdma-cm mutex being taken for the
duration of the double-loop...
Or.
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
