Patchwork [dpdk-dev,v8,10/10] doc: update ipsec-secgw guide and relelase notes

login
register
mail settings
Submitter Ananyev, Konstantin
Date Jan. 10, 2019, 9:09 p.m.
Message ID <1547154553-15814-11-git-send-email-konstantin.ananyev@intel.com>
Download mbox | patch
Permalink /patch/697333/
State New
Headers show

Comments

Ananyev, Konstantin - Jan. 10, 2019, 9:09 p.m.
Update ipsec-secgw guide and relelase notes to reflect latest changes.

Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
---
 doc/guides/rel_notes/release_19_02.rst   |  14 +++
 doc/guides/sample_app_ug/ipsec_secgw.rst | 105 ++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 2 deletions(-)
Varghese, Vipin - Jan. 11, 2019, 2:49 a.m.
Hi Konstantin,

As per 19.02-rc1, documentation has to be updated along with the code base. 

snipped
> --- a/doc/guides/rel_notes/release_19_02.rst
> +++ b/doc/guides/rel_notes/release_19_02.rst
> @@ -133,6 +133,20 @@ New Features
> 
>    See :doc:`../prog_guide/ipsec_lib` for more information.
> 
> +* **Updated the ipsec-secgw sample application.**
> +
> +  The ``ipsec-secgw`` sample application has been updated to use the
> + new  ``librte_ipsec`` library also added in this release.
> +  The original functionality of ipsec-secgw is retained, a new command
> + line  parameter ``-l`` has  been added to ipsec-secgw to use the IPsec
> + library,  instead of the existing IPsec code in the application.
> +
> +  The IPsec library does not support all the functionality of the
> + existing  ipsec-secgw application, its is planned to add the
> + outstanding functionality  in future releases.
> +
> +  See :doc:`../sample_app_ug/ipsec_secgw` for more information.
> +
> 
In my opinion this can come in the first patch 

snipped
>  #. [Optional] Build the application for debugging:
>     This option adds some extra flags, disables compiler optimizations and @@ -
> 93,6 +93,7 @@ The application has a number of command line options::
> 
>     ./build/ipsec-secgw [EAL options] --
>                          -p PORTMASK -P -u PORTMASK -j FRAMESIZE
> +                        -l -w REPLAY_WINOW_SIZE -e -a
This can be added patch which adds the option

>                          --config (port,queue,lcore)[,(port,queue,lcore]
>                          --single-sa SAIDX
>                          --rxoffload MASK @@ -114,6 +115,18 @@ Where:
>      specified as FRAMESIZE. If an invalid value is provided as FRAMESIZE
>      then the default value 9000 is used.
> 
> +*   ``-l``: enables code-path that uses librte_ipsec.
> +
> +*   ``-w REPLAY_WINOW_SIZE``: specifies the IPsec sequence number replay
> window
> +    size for each Security Association (available only with librte_ipsec
> +    code path).
> +
> +*   ``-e``: enables Security Association extended sequence number processing
> +    (available only with librte_ipsec code path).
> +
> +*   ``-a``: enables Security Association sequence number atomic behaviour
> +    (available only with librte_ipsec code path).
> +
>  *   ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which
> queues
>      from which ports are mapped to which cores.
> 
> @@ -225,7 +238,7 @@ accordingly.
> 
> 
>  Configuration File Syntax
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>  As mention in the overview, the Security Policies are ACL rules.
>  The application parsers the rules specified in the configuration file and @@ -
> 571,6 +584,11 @@ Example SA rules:
>      mode ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 \
>      type lookaside-protocol-offload port_id 4
> 
> +    sa in 35 aead_algo aes-128-gcm \
> +    aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
> +    mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 \
> +    type inline-crypto-offload port_id 0
> +
>  Routing rule syntax
>  ^^^^^^^^^^^^^^^^^^^
> 
> @@ -667,3 +685,86 @@ Example Neighbour rules:
>  .. code-block:: console
> 
>      neigh port 0 DE:AD:BE:EF:01:02
> +
> +Test directory
> +--------------
> +
> +The test directory contains scripts for testing the various encryption
> +algorithms.
> +
> +The purpose of the scripts is to automate ipsec-secgw testing using
> +another system running linux as a DUT.
> +
> +The user must setup the following environment variables:
> +
> +*   ``SGW_PATH``: path to the ipsec-secgw binary to test.
> +
> +*   ``REMOTE_HOST``: IP address/hostname of the DUT.
> +
> +*   ``REMOTE_IFACE``: interface name for the test-port on the DUT.
> +
> +*   ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-id>')
> +
> +Also the user can optionally setup:
> +
> +*   ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0)
> +
> +*   ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none specified
> +    appropriate vdevs will be created by the script
> +
> +Note that most of the tests require the appropriate crypto PMD/device
> +to be available.
> +
> +Server configuration
> +~~~~~~~~~~~~~~~~~~~~
> +
> +Two servers are required for the tests, SUT and DUT.
> +
> +Make sure the user from the SUT can ssh to the DUT without entering the
> password.
> +To enable this feature keys must be setup on the DUT.
> +
> +``ssh-keygen`` will make a private & public key pair on the SUT.
> +
> +``ssh-copy-id`` <user name>@<target host name> on the SUT will copy the
> +public key to the DUT. It will ask for credentials so that it can upload the
> public key.
> +
> +The SUT and DUT are connected through at least 2 NIC ports.
> +
> +One NIC port is expected to be managed by linux on both machines and
> +will be used as a control path.
> +
> +The second NIC port (test-port) should be bound to DPDK on the SUT, and
> +should be managed by linux on the DUT.
> +
> +The script starts ``ipsec-secgw`` with 2 NIC devices: ``test-port`` and
> +``tap vdev``.
> +
> +It then configures the local tap interface and the remote interface and
> +IPsec policies in the following way:
> +
> +Traffic going over the test-port in both directions has to be protected by
> IPsec.
> +
> +Traffic going over the TAP port in both directions does not have to be
> protected.
> +
> +i.e:
> +
> +DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
> +
> +SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
> +
> +It then tries to perform some data transfer using the scheme decribed above.
> +
> +usage
> +~~~~~
> +
> +In the ipsec-secgw/test directory
> +
> +to run one test for IPv4 or IPv6
> +
> +/bin/bash linux_test(4|6).sh <ipsec_mode>
> +
> +to run all tests for IPv4 or IPv6
> +
> +/bin/bash run_test.sh -4|-6
> +
> +For the list of available modes please refer to run_test.sh.
> --
> 2.17.1
akhil.goyal@nxp.com - Jan. 11, 2019, 6:56 a.m.
Hi Vipin,

On 1/11/2019 8:19 AM, Varghese, Vipin wrote:
> Hi Konstantin,

>

> As per 19.02-rc1, documentation has to be updated along with the code base.

I and Pablo, thought about your comment, but the feature that is added 
in this patchset is split across multiple patches (mainly 7/10 and 8/10) 
and it would be improper to add documentation in any of these patches.
So, it would be good to have a separate patch which is added when the 
feature is completely there.

>

> snipped

>> --- a/doc/guides/rel_notes/release_19_02.rst

>> +++ b/doc/guides/rel_notes/release_19_02.rst

>> @@ -133,6 +133,20 @@ New Features

>>

>>     See :doc:`../prog_guide/ipsec_lib` for more information.

>>

>> +* **Updated the ipsec-secgw sample application.**

>> +

>> +  The ``ipsec-secgw`` sample application has been updated to use the

>> + new  ``librte_ipsec`` library also added in this release.

>> +  The original functionality of ipsec-secgw is retained, a new command

>> + line  parameter ``-l`` has  been added to ipsec-secgw to use the IPsec

>> + library,  instead of the existing IPsec code in the application.

>> +

>> +  The IPsec library does not support all the functionality of the

>> + existing  ipsec-secgw application, its is planned to add the

>> + outstanding functionality  in future releases.

>> +

>> +  See :doc:`../sample_app_ug/ipsec_secgw` for more information.

>> +

>>

> In my opinion this can come in the first patch

>

> snipped

>>   #. [Optional] Build the application for debugging:

>>      This option adds some extra flags, disables compiler optimizations and @@ -

>> 93,6 +93,7 @@ The application has a number of command line options::

>>

>>      ./build/ipsec-secgw [EAL options] --

>>                           -p PORTMASK -P -u PORTMASK -j FRAMESIZE

>> +                        -l -w REPLAY_WINOW_SIZE -e -a

> This can be added patch which adds the option

>

>>                           --config (port,queue,lcore)[,(port,queue,lcore]

>>                           --single-sa SAIDX

>>                           --rxoffload MASK @@ -114,6 +115,18 @@ Where:

>>       specified as FRAMESIZE. If an invalid value is provided as FRAMESIZE

>>       then the default value 9000 is used.

>>

>> +*   ``-l``: enables code-path that uses librte_ipsec.

>> +

>> +*   ``-w REPLAY_WINOW_SIZE``: specifies the IPsec sequence number replay

>> window

>> +    size for each Security Association (available only with librte_ipsec

>> +    code path).

>> +

>> +*   ``-e``: enables Security Association extended sequence number processing

>> +    (available only with librte_ipsec code path).

>> +

>> +*   ``-a``: enables Security Association sequence number atomic behaviour

>> +    (available only with librte_ipsec code path).

>> +

>>   *   ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which

>> queues

>>       from which ports are mapped to which cores.

>>

>> @@ -225,7 +238,7 @@ accordingly.

>>

>>

>>   Configuration File Syntax

>> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>> +~~~~~~~~~~~~~~~~~~~~~~~~~

>>

>>   As mention in the overview, the Security Policies are ACL rules.

>>   The application parsers the rules specified in the configuration file and @@ -

>> 571,6 +584,11 @@ Example SA rules:

>>       mode ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 \

>>       type lookaside-protocol-offload port_id 4

>>

>> +    sa in 35 aead_algo aes-128-gcm \

>> +    aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \

>> +    mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 \

>> +    type inline-crypto-offload port_id 0

>> +

>>   Routing rule syntax

>>   ^^^^^^^^^^^^^^^^^^^

>>

>> @@ -667,3 +685,86 @@ Example Neighbour rules:

>>   .. code-block:: console

>>

>>       neigh port 0 DE:AD:BE:EF:01:02

>> +

>> +Test directory

>> +--------------

>> +

>> +The test directory contains scripts for testing the various encryption

>> +algorithms.

>> +

>> +The purpose of the scripts is to automate ipsec-secgw testing using

>> +another system running linux as a DUT.

>> +

>> +The user must setup the following environment variables:

>> +

>> +*   ``SGW_PATH``: path to the ipsec-secgw binary to test.

>> +

>> +*   ``REMOTE_HOST``: IP address/hostname of the DUT.

>> +

>> +*   ``REMOTE_IFACE``: interface name for the test-port on the DUT.

>> +

>> +*   ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-id>')

>> +

>> +Also the user can optionally setup:

>> +

>> +*   ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0)

>> +

>> +*   ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none specified

>> +    appropriate vdevs will be created by the script

>> +

>> +Note that most of the tests require the appropriate crypto PMD/device

>> +to be available.

>> +

>> +Server configuration

>> +~~~~~~~~~~~~~~~~~~~~

>> +

>> +Two servers are required for the tests, SUT and DUT.

>> +

>> +Make sure the user from the SUT can ssh to the DUT without entering the

>> password.

>> +To enable this feature keys must be setup on the DUT.

>> +

>> +``ssh-keygen`` will make a private & public key pair on the SUT.

>> +

>> +``ssh-copy-id`` <user name>@<target host name> on the SUT will copy the

>> +public key to the DUT. It will ask for credentials so that it can upload the

>> public key.

>> +

>> +The SUT and DUT are connected through at least 2 NIC ports.

>> +

>> +One NIC port is expected to be managed by linux on both machines and

>> +will be used as a control path.

>> +

>> +The second NIC port (test-port) should be bound to DPDK on the SUT, and

>> +should be managed by linux on the DUT.

>> +

>> +The script starts ``ipsec-secgw`` with 2 NIC devices: ``test-port`` and

>> +``tap vdev``.

>> +

>> +It then configures the local tap interface and the remote interface and

>> +IPsec policies in the following way:

>> +

>> +Traffic going over the test-port in both directions has to be protected by

>> IPsec.

>> +

>> +Traffic going over the TAP port in both directions does not have to be

>> protected.

>> +

>> +i.e:

>> +

>> +DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS

>> +

>> +SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS

>> +

>> +It then tries to perform some data transfer using the scheme decribed above.

>> +

>> +usage

>> +~~~~~

>> +

>> +In the ipsec-secgw/test directory

>> +

>> +to run one test for IPv4 or IPv6

>> +

>> +/bin/bash linux_test(4|6).sh <ipsec_mode>

>> +

>> +to run all tests for IPv4 or IPv6

>> +

>> +/bin/bash run_test.sh -4|-6

>> +

>> +For the list of available modes please refer to run_test.sh.

>> --

>> 2.17.1
Varghese, Vipin - Jan. 11, 2019, 8:11 a.m.
Hi Akhil,

Thanks for considering, as mentioned it is suggestion from my end how the document could have been updated.

Thanks
Vipin Varghese

> -----Original Message-----

> From: Akhil Goyal <akhil.goyal@nxp.com>

> Sent: Friday, January 11, 2019 12:26 PM

> To: Varghese, Vipin <vipin.varghese@intel.com>; Ananyev, Konstantin

> <konstantin.ananyev@intel.com>; dev@dpdk.org

> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>;

> thomas@monjalon.net; Iremonger, Bernard <bernard.iremonger@intel.com>

> Subject: Re: [dpdk-dev] [PATCH v8 10/10] doc: update ipsec-secgw guide and

> relelase notes

> 

> Hi Vipin,

> 

> On 1/11/2019 8:19 AM, Varghese, Vipin wrote:

> > Hi Konstantin,

> >

> > As per 19.02-rc1, documentation has to be updated along with the code

> base.

> I and Pablo, thought about your comment, but the feature that is added in this

> patchset is split across multiple patches (mainly 7/10 and 8/10) and it would

> be improper to add documentation in any of these patches.

> So, it would be good to have a separate patch which is added when the

> feature is completely there.

> 

> >

> > snipped

> >> --- a/doc/guides/rel_notes/release_19_02.rst

> >> +++ b/doc/guides/rel_notes/release_19_02.rst

> >> @@ -133,6 +133,20 @@ New Features

> >>

> >>     See :doc:`../prog_guide/ipsec_lib` for more information.

> >>

> >> +* **Updated the ipsec-secgw sample application.**

> >> +

> >> +  The ``ipsec-secgw`` sample application has been updated to use the

> >> + new  ``librte_ipsec`` library also added in this release.

> >> +  The original functionality of ipsec-secgw is retained, a new

> >> + command line  parameter ``-l`` has  been added to ipsec-secgw to

> >> + use the IPsec library,  instead of the existing IPsec code in the application.

> >> +

> >> +  The IPsec library does not support all the functionality of the

> >> + existing  ipsec-secgw application, its is planned to add the

> >> + outstanding functionality  in future releases.

> >> +

> >> +  See :doc:`../sample_app_ug/ipsec_secgw` for more information.

> >> +

> >>

> > In my opinion this can come in the first patch

> >

> > snipped

> >>   #. [Optional] Build the application for debugging:

> >>      This option adds some extra flags, disables compiler

> >> optimizations and @@ -

> >> 93,6 +93,7 @@ The application has a number of command line options::

> >>

> >>      ./build/ipsec-secgw [EAL options] --

> >>                           -p PORTMASK -P -u PORTMASK -j FRAMESIZE

> >> +                        -l -w REPLAY_WINOW_SIZE -e -a

> > This can be added patch which adds the option

> >

> >>                           --config (port,queue,lcore)[,(port,queue,lcore]

> >>                           --single-sa SAIDX

> >>                           --rxoffload MASK @@ -114,6 +115,18 @@ Where:

> >>       specified as FRAMESIZE. If an invalid value is provided as FRAMESIZE

> >>       then the default value 9000 is used.

> >>

> >> +*   ``-l``: enables code-path that uses librte_ipsec.

> >> +

> >> +*   ``-w REPLAY_WINOW_SIZE``: specifies the IPsec sequence number

> replay

> >> window

> >> +    size for each Security Association (available only with librte_ipsec

> >> +    code path).

> >> +

> >> +*   ``-e``: enables Security Association extended sequence number

> processing

> >> +    (available only with librte_ipsec code path).

> >> +

> >> +*   ``-a``: enables Security Association sequence number atomic behaviour

> >> +    (available only with librte_ipsec code path).

> >> +

> >>   *   ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which

> >> queues

> >>       from which ports are mapped to which cores.

> >>

> >> @@ -225,7 +238,7 @@ accordingly.

> >>

> >>

> >>   Configuration File Syntax

> >> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> >> +~~~~~~~~~~~~~~~~~~~~~~~~~

> >>

> >>   As mention in the overview, the Security Policies are ACL rules.

> >>   The application parsers the rules specified in the configuration

> >> file and @@ -

> >> 571,6 +584,11 @@ Example SA rules:

> >>       mode ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 \

> >>       type lookaside-protocol-offload port_id 4

> >>

> >> +    sa in 35 aead_algo aes-128-gcm \

> >> +    aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \

> >> +    mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 \

> >> +    type inline-crypto-offload port_id 0

> >> +

> >>   Routing rule syntax

> >>   ^^^^^^^^^^^^^^^^^^^

> >>

> >> @@ -667,3 +685,86 @@ Example Neighbour rules:

> >>   .. code-block:: console

> >>

> >>       neigh port 0 DE:AD:BE:EF:01:02

> >> +

> >> +Test directory

> >> +--------------

> >> +

> >> +The test directory contains scripts for testing the various

> >> +encryption algorithms.

> >> +

> >> +The purpose of the scripts is to automate ipsec-secgw testing using

> >> +another system running linux as a DUT.

> >> +

> >> +The user must setup the following environment variables:

> >> +

> >> +*   ``SGW_PATH``: path to the ipsec-secgw binary to test.

> >> +

> >> +*   ``REMOTE_HOST``: IP address/hostname of the DUT.

> >> +

> >> +*   ``REMOTE_IFACE``: interface name for the test-port on the DUT.

> >> +

> >> +*   ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-

> id>')

> >> +

> >> +Also the user can optionally setup:

> >> +

> >> +*   ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0)

> >> +

> >> +*   ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none

> specified

> >> +    appropriate vdevs will be created by the script

> >> +

> >> +Note that most of the tests require the appropriate crypto

> >> +PMD/device to be available.

> >> +

> >> +Server configuration

> >> +~~~~~~~~~~~~~~~~~~~~

> >> +

> >> +Two servers are required for the tests, SUT and DUT.

> >> +

> >> +Make sure the user from the SUT can ssh to the DUT without entering

> >> +the

> >> password.

> >> +To enable this feature keys must be setup on the DUT.

> >> +

> >> +``ssh-keygen`` will make a private & public key pair on the SUT.

> >> +

> >> +``ssh-copy-id`` <user name>@<target host name> on the SUT will copy

> >> +the public key to the DUT. It will ask for credentials so that it

> >> +can upload the

> >> public key.

> >> +

> >> +The SUT and DUT are connected through at least 2 NIC ports.

> >> +

> >> +One NIC port is expected to be managed by linux on both machines and

> >> +will be used as a control path.

> >> +

> >> +The second NIC port (test-port) should be bound to DPDK on the SUT,

> >> +and should be managed by linux on the DUT.

> >> +

> >> +The script starts ``ipsec-secgw`` with 2 NIC devices: ``test-port``

> >> +and ``tap vdev``.

> >> +

> >> +It then configures the local tap interface and the remote interface

> >> +and IPsec policies in the following way:

> >> +

> >> +Traffic going over the test-port in both directions has to be

> >> +protected by

> >> IPsec.

> >> +

> >> +Traffic going over the TAP port in both directions does not have to

> >> +be

> >> protected.

> >> +

> >> +i.e:

> >> +

> >> +DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT

> >> +OS

> >> +

> >> +SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS

> >> +

> >> +It then tries to perform some data transfer using the scheme decribed

> above.

> >> +

> >> +usage

> >> +~~~~~

> >> +

> >> +In the ipsec-secgw/test directory

> >> +

> >> +to run one test for IPv4 or IPv6

> >> +

> >> +/bin/bash linux_test(4|6).sh <ipsec_mode>

> >> +

> >> +to run all tests for IPv4 or IPv6

> >> +

> >> +/bin/bash run_test.sh -4|-6

> >> +

> >> +For the list of available modes please refer to run_test.sh.

> >> --

> >> 2.17.1
Thomas Monjalon - Jan. 12, 2019, 11:49 p.m.
10/01/2019 22:09, Konstantin Ananyev:
> Update ipsec-secgw guide and relelase notes to reflect latest changes.
> 
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> ---
>  doc/guides/rel_notes/release_19_02.rst   |  14 +++
>  doc/guides/sample_app_ug/ipsec_secgw.rst | 105 ++++++++++++++++++++++-

This new file is missing in MAINTAINERS. I'll add it.

Patch

diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index fe231152f..d824d66bb 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -133,6 +133,20 @@  New Features
 
   See :doc:`../prog_guide/ipsec_lib` for more information.
 
+* **Updated the ipsec-secgw sample application.**
+
+  The ``ipsec-secgw`` sample application has been updated to use the new
+  ``librte_ipsec`` library also added in this release.
+  The original functionality of ipsec-secgw is retained, a new command line
+  parameter ``-l`` has  been added to ipsec-secgw to use the IPsec library,
+  instead of the existing IPsec code in the application.
+
+  The IPsec library does not support all the functionality of the existing
+  ipsec-secgw application, its is planned to add the outstanding functionality
+  in future releases.
+
+  See :doc:`../sample_app_ug/ipsec_secgw` for more information.
+
 
 Removed Items
 -------------
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst
index 61638e733..3d784e705 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -76,7 +76,7 @@  Compiling the Application
 
 To compile the sample application see :doc:`compiling`.
 
-The application is located in the ``rpsec-secgw`` sub-directory.
+The application is located in the ``ipsec-secgw`` sub-directory.
 
 #. [Optional] Build the application for debugging:
    This option adds some extra flags, disables compiler optimizations and
@@ -93,6 +93,7 @@  The application has a number of command line options::
 
    ./build/ipsec-secgw [EAL options] --
                         -p PORTMASK -P -u PORTMASK -j FRAMESIZE
+                        -l -w REPLAY_WINOW_SIZE -e -a
                         --config (port,queue,lcore)[,(port,queue,lcore]
                         --single-sa SAIDX
                         --rxoffload MASK
@@ -114,6 +115,18 @@  Where:
     specified as FRAMESIZE. If an invalid value is provided as FRAMESIZE
     then the default value 9000 is used.
 
+*   ``-l``: enables code-path that uses librte_ipsec.
+
+*   ``-w REPLAY_WINOW_SIZE``: specifies the IPsec sequence number replay window
+    size for each Security Association (available only with librte_ipsec
+    code path).
+
+*   ``-e``: enables Security Association extended sequence number processing
+    (available only with librte_ipsec code path).
+
+*   ``-a``: enables Security Association sequence number atomic behaviour
+    (available only with librte_ipsec code path).
+
 *   ``--config (port,queue,lcore)[,(port,queue,lcore)]``: determines which queues
     from which ports are mapped to which cores.
 
@@ -225,7 +238,7 @@  accordingly.
 
 
 Configuration File Syntax
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 As mention in the overview, the Security Policies are ACL rules.
 The application parsers the rules specified in the configuration file and
@@ -571,6 +584,11 @@  Example SA rules:
     mode ipv4-tunnel src 172.16.1.5 dst 172.16.2.5 \
     type lookaside-protocol-offload port_id 4
 
+    sa in 35 aead_algo aes-128-gcm \
+    aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \
+    mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 \
+    type inline-crypto-offload port_id 0
+
 Routing rule syntax
 ^^^^^^^^^^^^^^^^^^^
 
@@ -667,3 +685,86 @@  Example Neighbour rules:
 .. code-block:: console
 
     neigh port 0 DE:AD:BE:EF:01:02
+
+Test directory
+--------------
+
+The test directory contains scripts for testing the various encryption
+algorithms.
+
+The purpose of the scripts is to automate ipsec-secgw testing
+using another system running linux as a DUT.
+
+The user must setup the following environment variables:
+
+*   ``SGW_PATH``: path to the ipsec-secgw binary to test.
+
+*   ``REMOTE_HOST``: IP address/hostname of the DUT.
+
+*   ``REMOTE_IFACE``: interface name for the test-port on the DUT.
+
+*   ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-id>')
+
+Also the user can optionally setup:
+
+*   ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0)
+
+*   ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none specified
+    appropriate vdevs will be created by the script
+
+Note that most of the tests require the appropriate crypto PMD/device to be
+available.
+
+Server configuration
+~~~~~~~~~~~~~~~~~~~~
+
+Two servers are required for the tests, SUT and DUT.
+
+Make sure the user from the SUT can ssh to the DUT without entering the password.
+To enable this feature keys must be setup on the DUT.
+
+``ssh-keygen`` will make a private & public key pair on the SUT.
+
+``ssh-copy-id`` <user name>@<target host name> on the SUT will copy the public
+key to the DUT. It will ask for credentials so that it can upload the public key.
+
+The SUT and DUT are connected through at least 2 NIC ports.
+
+One NIC port is expected to be managed by linux on both machines and will be
+used as a control path.
+
+The second NIC port (test-port) should be bound to DPDK on the SUT, and should
+be managed by linux on the DUT.
+
+The script starts ``ipsec-secgw`` with 2 NIC devices: ``test-port`` and
+``tap vdev``.
+
+It then configures the local tap interface and the remote interface and IPsec
+policies in the following way:
+
+Traffic going over the test-port in both directions has to be protected by IPsec.
+
+Traffic going over the TAP port in both directions does not have to be protected.
+
+i.e:
+
+DUT OS(NIC1)--(IPsec)-->(NIC1)ipsec-secgw(TAP)--(plain)-->(TAP)SUT OS
+
+SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
+
+It then tries to perform some data transfer using the scheme decribed above.
+
+usage
+~~~~~
+
+In the ipsec-secgw/test directory
+
+to run one test for IPv4 or IPv6
+
+/bin/bash linux_test(4|6).sh <ipsec_mode>
+
+to run all tests for IPv4 or IPv6
+
+/bin/bash run_test.sh -4|-6
+
+For the list of available modes please refer to run_test.sh.