diff options
Diffstat (limited to 'config/odp-linux-generic.conf')
| -rw-r--r-- | config/odp-linux-generic.conf | 51 |
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 + } +} |