On Wed, 3 May 2017, Sowmini Varadhan wrote:
I am saying that if there are multiple TCP streams between the same
pair of IP addresses, we want each stream to get a different SPI.
For RDS-TCP, we have the concept of mprds:
https://www.spinics.net/lists/netdev/msg381424.html
where I pointed out that a single tcp stream can only give me
4 Gbps, but 8 streams (with 8 different client ports, single server port)
can give me 32 Gbps.
Today, without PFP, IPsec leaves me at single-stream throughput,
even when I have 8 TCP connections going on.
Oh, so you are looking at just solving the problem of 1 IPsec SA only
being served by 1 CPU? Then look into pcrypt:
https://libreswan.org/wiki/OCF_Hardware_crypto_acceleration#The_pcrypt_kernel_module
but yes, reordering can then happen and you need to set a larger
replay-window= or disable replay detection completely.
How does using different IPsec SA's per TCP stream get you anything?
See other mail about entropy. Everything that uses flow-based
parallelism (RSS at the host, ECMP at the switches) needs to be able to
spread flows across multiple paths, while making sure there is
no packet reordering within the flow.
having as much granularity in the flow-id as possible is the key
to getting this to work well.
So you want to use the SPI's to spread the flows. Okay, I guess I
understand that now, and that it is not an entropy source or something.
It seems using IKE to artificially split up an IPsec SA into multiple
ones to address a kernel issue is not the proper solution though.
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
