[Openswan dev] KLIPS tdb_lock as rwlock instead of spinlock?

[Jagdish Motwani]

Hi,
    Can tdb_lock be converted from spinlock to rwlock?

     From what i know, tdb_lock is used to protect sa.
                                  ipsec_xmit.c &  ipsec_rcv.c just uses 
them for reading(get) sa.


      While experimenting with KLIPS, i converted this tdb_lock to 
rwlock_t and performed the below given test.

      I got desired results but i am not sure about any side-effects of 
this conversion.  Please provide your valuable input.

/
     Test setup details:
                     LAN1 ----------
                                             Test Machine 
----------(Ipsec tunnel)---------------- Road warrior
                     LAN2 ----------


       Test Machine has 8 cores, I  have binded interrupts to only 3 of 
them:
                             LAN1 -- cpu1
                             LAN2 -- cpu2
                  Roadwarrior -- cpu3

       Traffic flows from LAN1 and LAN2 to Road warrior. (I used iperf 
to generate traffic: iperf server is at road warrior and clients in LAN1 
and LAN2).


     Changes done:
               1) in ipsec_tunnel.c
                          dev->tx_queue_len   = 0;        /* No qdisc 
*/   (Earlier it was 10)
                          dev->features |= NETIF_F_LLTX; /* No tx lock */

               2)Converted tdb_lock from spinlock_t to rwlock_t
                          Instead of spin_lock_bh used
                                         read_lock_bh in ipsec_xmit.c 
and ipsec_rcv.c
                                         write_lock_bh elsewhere
        Got throughput:
          Before Change: 225 Mbps    (cpu1 and cpu2  are  not being 100% 
utilized)
          After Change:    350 Mbps    (both cpus1 and cpu2 are being 
100% utilized)
/

     Also, One more question: Is there any know side effect of 
dev->tx_queue_len=0? Why is it 10  by default?

Regards,
Jagdish Motwani
Software Engineer
Elitecore Technologies Pvt. Ltd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openswan.org/pipermail/dev/attachments/20120411/2a5f6a59/attachment.html>