(usagi-users 03443) mip6d-2 handover performance

Dear all,

I have been observing the performance of the handover in the mip6d-2 and 
noticed the following situation:
upon receiving a router advertisement, in order to set a new CoA, the 
mip6d calls using a netlink socket the
kernel with an NEW_SA/UPD_SA message. The incoming message is handled by 
xfrm_recv_msg, which
calls in turn xfrm_add_sa which calls xfrm_probe_algs and checks for the 
available cryptographic algorithms.
For each of the algorithms to be checked it calls crypto_alg_available 
which tries to insert the corresponding
module, and by calling try_or_request_module goes to userspace for 
executing modprobe. Since modprobe
does disk access, it can take about 50msec/execution and about 200msec 
for the whole checking process to
continue. This blocks the router advertisement-processing thread in the 
mip6d (the thread is blocked in the
sendmsg call for the netlink socket) and the netlink-processing thread 
in the kernel, delaying the addition of the
new CoA for the new link. The succession of calls would be:
md_recv_ra
    __md_trigger_movement_event
       mn_movement_event
          mn_move
             do_handoff
                 send_home_bu
                      ................
                         mip6_state_add
                            rtnl_xfrm_do
                               rtnl_do
                                  rtnl_talk
                                    sendmsg --- here it goes into kernel 
space
                                      xfrm_netlink_rcv -- net/xfrm_user.c
                                        xfrm_user_rcv_skb
                                           xfrm_user_rcv_msg
                                              xfrm_add_sa
                                                 xfrm_probe_algs -- 
net/xfrm_algo.c
                                                   crypto_alg_available 
-- crypto/api.c
                                                       
try_or_request_module -- goes to kernel/kmod.c, takes up to 50msec to 
execute
                                                                        
                          since it can call modprobe in user-space; 
since this is
                                                                      
                            executed a few times the total delay is >200msec

Perhaps the situation described is the worst-case scenario, since we do not
use IPsec, so the kernel tries to find the modules every time. It seems 
that the time spent in the kernel is quite large, and
the handover performance has to suffer since the new CoA cannot be used 
in the meanwhile (as Ethereal traces show).
Perhaps it would be better to have the tables of cryptographic 
algorithms as static variables and only initialize them once.

Regards,
Vlad Balan