[ofa-general] Re: [RFC V3 PATCH 4/5] rdma/cma: implement RDMA_CM_EVENT_NETDEV_CHANGE notification

Or Gerlitz ogerlitz at voltaire.com
Wed May 28 04:31:15 PDT 2008


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.




More information about the general mailing list