(usagi-users 03445) Re: mip6d-2 handover performance

[Masahide NAKAMURA <nakam@xxxxxxxxxxxxxx>]

It is already removed from the mainline kernel since 2.6.11,
about what xfrm_probe_algs() is called by xfrm_add_state()
at xfrm_user.c (to avoid trying modprobe if all algorithm doesn't
exist in adding a SA).

Then, it doesn't matter when MIPL kernel patch is
ready for newer kernel version (2.6.11 or later).

Regards,


Vlad Balan wrote:
> 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
>        


--
Masahide NAKAMURA