Michael S. Tsirkin wrote: >> Quoting Moni Shoua <[EMAIL PROTECTED]>: >> Subject: Re: [openib-general] [RFC] [PATCH v2] IB/ipoib: Add bonding support >> to IPoIB >> >> Michael S. Tsirkin wrote: >>>> Quoting Moni Shoua <[EMAIL PROTECTED]>: >>>> Subject: Re: [openib-general] [RFC] [PATCH v2] IB/ipoib: Add bonding >>>> support to IPoIB >>>> >>>> This version of the patch tracks the allocs and releases of ipoib_neigh and >>>> keeps a list of them. Before IPoIB net device unregisters the list is >>>> passed >>>> to destroy ipoib_neighs that ride on on a bond neighbour. >>>> >>>> This is a replacement to the method of scanning the arp and ndisc >>>> tables. >>> Why does the list need to be global? >>> We already have a per-device list of paths, and each of these in turn >>> has a list of neighbours. Can't this be used? >>> >> OK, It's a good point but coming to think of it now I have a question >> >> When a device unregisters ipoib_stop() is called and all ipoib_neighs are >> destroyed. >> Isn't it enough to ensure that ipoib_neigh_destructor will not try to >> "touch" one of the ib devs? or in other words: Isn't it that the work to >> clean ipoib_neighs is unnecessary? >> Michael, Do you agree that destroying the ipoib_neighs through (a call trace that starts with) ipoib_stop() is enough for safety and that there is no need to do that just before calling to unregister_netdev() ?
>> BTW: I guess that idea of global list was influenced from the ipoib_8111... >> patch. >> Why was it used there? > > AFAIK, the point is to check whether (in pre-2.6.17 kernels) some neighbour > shares the same ops pointer. Only after no such neighbours are left is it safe > to set the destructor to NULL. > > This backport is not raceless BTW - some neighbour not related to IPoIB could > be running the destructor. But I think it's the best I could come up with > for these old kernels. > _______________________________________________ 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
