On Tue, Aug 19, 2014 at 1:32 PM, Doug Ledford <[email protected]> wrote: > Whether or not the core network code is OK with us dropping the rtnl lock > while manipulating the interface is the issue here. However, I did consider > changing the mcast_mutex to a per interface lock instead. The are various > optimizations that can be made now that the locking is correct and race free > and that we don't flush from the workqueue we are flushing. I didn't go into > those changes in this set. As for 20ms, I did that because checkpatch > complains about shorter waits and I don't like to busy loop, especially since > it's not like this is a performance sensitive section of code. >
I'm acking this patch for now. However, I want to remind everyone that rntl is a "BIG" global lock that has been used by other net devices such as Ethernet. It is particularly troublesome for us since the IPOIB needs to co-exist with Ethernet interface that has non-trivial amount of traffic as well. Imaging everyone tries to bring their interfaces up/down all together in a large cluster environment that needs to worry about power consumption. It would be "cool" if we can see less of this lock ! Acked-by: Wendy Cheng <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
