This list is intended for people who want to be involved with the development and design of OpenSWAN. ()

Jagdish Motwani | 17 Apr 2012 10:41

[Openswan dev] RFC KLIPS patch for increased throughput on multicore systems

Ref mail: KLIPS tdb_lock as rwlock instead of spinlock?

Please find attached klips patch for increased throughput of single 
tunnel on multicore systems.

This patch is just a RFC and may have side effects. Please report them 
by testing or code review.

In-order to get increased throughput,
         1)Apply the patch
         2)Use Receive Packet Steering to send packets of different 
flows on different cpu's (/sys/class/net/eth0/queues/rx-0/rps_cpus)

Regrads,
Jagdish Motwani
Software Engineer
Elitecore Technologies Pvt. Ltd.

diff --git a/linux/include/openswan/ipsec_proto.h b/linux/include/openswan/ipsec_proto.h
index f40336c..db21b92 100644
--- a/linux/include/openswan/ipsec_proto.h
+++ b/linux/include/openswan/ipsec_proto.h
 <at>  <at>  -41,7 +41,7  <at>  <at>  extern struct prng ipsec_prng;

 /* ipsec_sa.c */
 extern struct ipsec_sa *ipsec_sadb_hash[SADB_HASHMOD];
-extern spinlock_t       tdb_lock;
+extern rwlock_t tdb_lock;
 extern int ipsec_sadb_init(void);

(Continue reading)

headers

David McCullough | 17 Apr 2012 12:32

Re: [Openswan dev] RFC KLIPS patch for increased throughput on multicore systems


Jivin Jagdish Motwani lays it down ...
> Ref mail: KLIPS tdb_lock as rwlock instead of spinlock?
> 
> Please find attached klips patch for increased throughput of single 
> tunnel on multicore systems.
> 
> This patch is just a RFC and may have side effects. Please report them 
> by testing or code review.
> 
> In-order to get increased throughput,
>          1)Apply the patch
>          2)Use Receive Packet Steering to send packets of different 
> flows on different cpu's (/sys/class/net/eth0/queues/rx-0/rps_cpus)

The patch is clean and simple,  but I am not sure if there is anything we
are missing here.

I'll try and get this loaded on a few different systems here and try it out.
Especially on an SMP OCF system just to check that angle as well.

At the end of the day we just need to be sure the SA table doesn't get
modified in any way while the state machine is using it.

My only suggestion would be to set a really short rekey time and run with
that while you are benchmarking.  Maybe have 3 or 4 tunnels rekeying while
you are benchmarking if possible.

Given the performance improvements you have shown I think we need to look at
something like this no matter what,  hopefully this patch is it

(Continue reading)