On Mon, Apr 22, 2013 at 1:18 PM, David Miller <da...@davemloft.net> wrote: > From: Pravin B Shelar <pshe...@nicira.com> > Date: Thu, 18 Apr 2013 14:30:46 -0700 > >> All genl callbacks are serialized by genl-mutex. This can become >> bottleneck in multi threaded case. >> Following patch adds an parameter to genl_family so that a >> particular family can get concurrent netlink callback without >> genl_lock held. >> New rw-sem is used to protect genl callback from genl family unregister. >> in case of lockless genl-family read-lock is taken for callbacks and >> write lock is taken for register or unregistration for any family. >> In case of locked genl family semaphore and gel-mutex is locked for >> any openration. >> >> Signed-off-by: Pravin B Shelar <pshe...@nicira.com> > > I don't think you can do this. > > Dumps happen in several passes, and the dumps keep track of where > we are in the dump by using a scratchpad in the SKB. That means > we have state that must stay sane across several dump invocations. > Sorry for confusion, GENL still have netlink lock to protect dump operation (nlk->cb_mutex). With this change that mutex is changed from global genl_lock to per socket lock by changing netlink_kernel_cfg in genl_pernet_init(). Therefore scatchpad in SKB is protected and parallel netlink dump operations can go only on different netlink sockets.
> This means we have to keep out set operations while the dump is > happening. > > That means we have to hold a mutex over all configurations changes. > right, Thats why I have introduced new rw-sem. Read lock is taken for all callback and dump operations and all configuration changes needs write lock on the semaphore. So that it is mutually exclusive. Let me know if I am missing something. > I do not like this change, and don't intend to apply it nor the > openvswitch stuff. > > If you don't like my position, get one of the netlink experts to > chime in since none of them have reviewed this stuff yet. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
