[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