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.go...@nxp.com>
> Sent: Friday, January 11, 2019 12:26 PM
> To: Varghese, Vipin <vipin.vargh...@intel.com>; Ananyev, Konstantin
> <konstantin.anan...@intel.com>; dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>;
> tho...@monjalon.net; Iremonger, Bernard <bernard.iremon...@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
