linux-gen: ipsec: add configurable ordering mode

Add new config file parameters to control how original input queue
order is maintained during asynchronous IPsec processing.

When asynchronous IPsec operations are started within an ordered
scheduling context, packet order is maintained in IPsec completion
queues but the order in which the sequence number gets assigned or
the anti-replay check done is not guaranteed. This commit adds a config
option to force the stateful part of IPsec processing to be done in the
correct order, at the cost of reduced parallelism.

The ordering mechanism added in this commit uses the order_lock method
of the internal scheduling API to stop the calling thread until it
is its turn (i.e the preceding scheduling contexts associated with the
same input queue have been released). Future commits may add more
elaborate mechanisms.

The default behaviour does not change. By default no ordering is done.

Signed-off-by: Janne Peltonen <janne.peltonen@nokia.com>
Reviewed-by: Jere Leppänen <jere.leppanen@nokia.com>

1 files changed, 50 insertions, 1 deletions

diff --git a/config/odp-linux-generic.conf b/config/odp-linux-generic.conf
index 8469b72d7..3ac3e3e58 100644
--- a/config/odp-linux-generic.conf
+++ b/config/odp-linux-generic.conf
@@ -16,7 +16,7 @@
 
 # Mandatory fields
 odp_implementation = "linux-generic"
-config_file_version = "0.1.15"
+config_file_version = "0.1.16"
 
 # System options
 system: {
@@ -234,3 +234,52 @@ timer: {
 	# 2: Only control threads process non-private timer pools
 	inline_thread_type = 0
 }
+
+ipsec: {
+	# Packet ordering method for asynchronous IPsec processing
+	#
+	# Asynchronous IPsec processing maintains original packet order when
+	# started within ordered or atomic scheduling context. In addition
+	# to that, ODP API specifies that the order of IPsec processing
+	# (i.e. anti-replay window update and sequence number generation)
+	# is the same as the original packet order.
+	#
+	# The following settings control how the order is maintained in
+	# asynchronous IPsec operations. They have no effect on synchronous
+	# operations where the ODP application is responsible of the ordering.
+	#
+	# Values:
+	#
+	# 0: Ordering is not attempted.
+	#
+	#    This has the lowest overhead and the greatest parallelism but
+	#    is not fully compliant with the API specification.
+	#
+	#    Lack of ordering means that outbound IPsec packets, although
+	#    remaining in the correct order, may have their sequence numbers
+	#    assigned out of order. This can cause unexpected packet loss if
+	#    the anti-replay window of the receiving end is not large enough
+	#    to cover the possible misordering.
+	#
+	#    Similarly, since anti-replay check is not done in the reception
+	#    order, the anti-replay check sees additional packet misordering
+	#    on top of the true misordering of the received packets. This
+	#    means that a larger anti-replay window may be required to avoid
+	#    packet loss.
+	#
+	# 1: Ordering by waiting
+	#
+	#    Correct processing order is maintained by a simple mechanism
+	#    that makes a thread wait until its scheduling context has
+	#    reached the head of its input queue.
+	#
+	#    This limits parallelism when single input queue is used, even
+	#    when packets get distributed to multiple SAs.
+	ordering: {
+		  # Odering method for asynchronous inbound operations.
+		  async_inbound = 0
+
+		  # Odering method for asynchronous outbound operations.
+		  async_outbound = 0
+	}
+}