From: Aviad Yehezkel <aviadye@dev.mellanox.co.il>
To: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v4 02/12] doc: add details of rte security
Date: Sun, 15 Oct 2017 15:47:48 +0300 [thread overview]
Message-ID: <8f9b1446-d80b-3cf5-602e-032538456c9f@dev.mellanox.co.il> (raw)
In-Reply-To: <20171014221734.15511-3-akhil.goyal@nxp.com>
On 10/15/2017 1:17 AM, Akhil Goyal wrote:
> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com>
> Acked-by: John McNamara <john.mcnamara@intel.com>
> ---
> doc/api/doxy-api-index.md | 3 +-
> doc/api/doxy-api.conf | 1 +
> doc/guides/prog_guide/index.rst | 1 +
> doc/guides/prog_guide/rte_security.rst | 559 +++++++++++++++++++++++++++++++++
> 4 files changed, 563 insertions(+), 1 deletion(-)
> create mode 100644 doc/guides/prog_guide/rte_security.rst
>
> diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md
> index 990815f..7c680dc 100644
> --- a/doc/api/doxy-api-index.md
> +++ b/doc/api/doxy-api-index.md
> @@ -58,7 +58,8 @@ The public API headers are grouped by topics:
> [ixgbe] (@ref rte_pmd_ixgbe.h),
> [i40e] (@ref rte_pmd_i40e.h),
> [bnxt] (@ref rte_pmd_bnxt.h),
> - [crypto_scheduler] (@ref rte_cryptodev_scheduler.h)
> + [crypto_scheduler] (@ref rte_cryptodev_scheduler.h),
> + [security] (@ref rte_security.h)
>
> - **memory**:
> [memseg] (@ref rte_memory.h),
> diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
> index 9e9fa56..567691b 100644
> --- a/doc/api/doxy-api.conf
> +++ b/doc/api/doxy-api.conf
> @@ -70,6 +70,7 @@ INPUT = doc/api/doxy-api-index.md \
> lib/librte_reorder \
> lib/librte_ring \
> lib/librte_sched \
> + lib/librte_security \
> lib/librte_table \
> lib/librte_timer \
> lib/librte_vhost
> diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
> index b5ad6b8..46cb4fe 100644
> --- a/doc/guides/prog_guide/index.rst
> +++ b/doc/guides/prog_guide/index.rst
> @@ -46,6 +46,7 @@ Programmer's Guide
> rte_flow
> traffic_management
> cryptodev_lib
> + rte_security
> link_bonding_poll_mode_drv_lib
> timer_lib
> hash_lib
> diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst
> new file mode 100644
> index 0000000..0708856
> --- /dev/null
> +++ b/doc/guides/prog_guide/rte_security.rst
> @@ -0,0 +1,559 @@
> +.. BSD LICENSE
> + Copyright 2017 NXP.
> +
> + Redistribution and use in source and binary forms, with or without
> + modification, are permitted provided that the following conditions
> + are met:
> +
> + * Redistributions of source code must retain the above copyright
> + notice, this list of conditions and the following disclaimer.
> + * Redistributions in binary form must reproduce the above copyright
> + notice, this list of conditions and the following disclaimer in
> + the documentation and/or other materials provided with the
> + distribution.
> + * Neither the name of NXP nor the names of its
> + contributors may be used to endorse or promote products derived
> + from this software without specific prior written permission.
> +
> + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +
> +
> +Security Library
> +================
> +
> +The security library provides a framework for management and provisioning
> +of security protocol operations offloaded to hardware based devices. The
> +library defines generic APIs to create and free security sessions which can
> +support full protocol offload as well as inline crypto operation with
> +NIC or crypto devices. The framework currently only supports the IPSec protocol
> +and associated operations, other protocols will be added in future.
> +
> +Design Principles
> +-----------------
> +
> +The security library provides an additional offload capability to an existing
> +crypto device and/or ethernet device.
> +
> +.. code-block:: console
> +
> + +---------------+
> + | rte_security |
> + +---------------+
> + \ /
> + +-----------+ +--------------+
> + | NIC PMD | | CRYPTO PMD |
> + +-----------+ +--------------+
> +
> +The supported offload types are explained in the sections below.
> +
> +Inline Crypto
> +~~~~~~~~~~~~~
> +
> +RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
> +The crypto processing for security protocol (e.g. IPSec) is processed
> +inline during receive and transmission on NIC port. The flow based
> +security action should be configured on the port.
> +
> +Ingress Data path - The packet is decrypted in RX path and relevant
> +crypto status is set in Rx descriptors. After the successful inline
> +crypto processing the packet is presented to host as a regular Rx packet
> +however all security protocol related headers are still attached to the
> +packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
> +ESP/AH headers will remain in the packet but the received packet
> +contains the decrypted data where the encrypted data was when the packet
> +arrived. The driver Rx path check the descriptors and and based on the
> +crypto status sets additional flags in the rte_mbuf.ol_flags field.
> +
> +.. note::
> +
> + The underlying device may not support crypto processing for all ingress packet
> + matching to a particular flow (e.g. fragmented packets), such packets will
> + be passed as encrypted packets. It is the responsibility of application to
> + process such encrypted packets using other crypto driver instance.
> +
> +Egress Data path - The software prepares the egress packet by adding
> +relevant security protocol headers. Only the data will not be
> +encrypted by the software. The driver will accordingly configure the
> +tx descriptors. The hardware device will encrypt the data before sending the
> +the packet out.
> +
> +.. note::
> +
> + The underlying device may support post encryption TSO.
> +
> +.. code-block:: console
> +
> + Egress Data Path
> + |
> + +--------|--------+
> + | egress IPsec |
> + | | |
> + | +------V------+ |
> + | | SADB lookup | |
> + | +------|------+ |
> + | +------V------+ |
> + | | Tunnel | | <------ Add tunnel header to packet
> + | +------|------+ |
> + | +------V------+ |
> + | | ESP | | <------ Add ESP header without trailer to packet
> + | | | | <------ Mark packet to be offloaded, add trailer
> + | +------|------+ | meta-data to mbuf
> + +--------V--------+
> + |
> + +--------V--------+
> + | L2 Stack |
> + +--------|--------+
> + |
> + +--------V--------+
> + | |
> + | NIC PMD | <------ Set hw context for inline crypto offload
> + | |
> + +--------|--------+
> + |
> + +--------|--------+
> + | HW ACCELERATED | <------ Packet Encryption and
> + | NIC | Authentication happens inline
> + | |
> + +-----------------+
> +
> +
> +Inline protocol offload
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
> +The crypto and protocol processing for security protocol (e.g. IPSec)
> +is processed inline during receive and transmission. The flow based
> +security action should be configured on the port.
> +
> +Ingress Data path - The packet is decrypted in the RX path and relevant
> +crypto status is set in the Rx descriptors. After the successful inline
> +crypto processing the packet is presented to the host as a regular Rx packet
> +but all security protocol related headers are optionally removed from the
> +packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
> +ESP/AH headers will be removed from the packet and the received packet
> +will contains the decrypted packet only. The driver Rx path checks the
> +descriptors and based on the crypto status sets additional flags in
> +``rte_mbuf.ol_flags`` field.
> +
> +.. note::
> +
> + The underlying device in this case is stateful. It is expected that
> + the device shall support crypto processing for all kind of packets matching
> + to a given flow, this includes fragmented packets (post reassembly).
> + E.g. in case of IPSec the device may internally manage anti-replay etc.
> + It will provide a configuration option for anti-replay behavior i.e. to drop
> + the packets or pass them to driver with error flags set in the descriptor.
> +
> +Egress Data path - The software will send the plain packet without any
> +security protocol headers added to the packet. The driver will configure
> +the security index and other requirement in tx descriptors.
> +The hardware device will do security processing on the packet that includes
> +adding the relevant protocol headers and encrypting the data before sending
> +the packet out. The software should make sure that the buffer
> +has required head room and tail room for any protocol header addition. The
> +software may also do early fragmentation if the resultant packet is expected
> +to cross the MTU size.
> +
> +
> +.. note::
> +
> + The underlying device will manage state information required for egress
> + processing. E.g. in case of IPSec, the seq number will be added to the
> + packet, however the device shall provide indication when the sequence number
> + is about to overflow. The underlying device may support post encryption TSO.
> +
> +.. code-block:: console
> +
> + Egress Data Path
> + |
> + +--------|--------+
> + | egress IPsec |
> + | | |
> + | +------V------+ |
> + | | SADB lookup | |
> + | +------|------+ |
> + | +------V------+ |
> + | | Desc | | <------ Mark packet to be offloaded
> + | +------|------+ |
> + +--------V--------+
> + |
> + +--------V--------+
> + | L2 Stack |
> + +--------|--------+
> + |
> + +--------V--------+
> + | |
> + | NIC PMD | <------ Set hw context for inline crypto offload
> + | |
> + +--------|--------+
> + |
> + +--------|--------+
> + | HW ACCELERATED | <------ Add tunnel, ESP header etc header to
> + | NIC | packet. Packet Encryption and
> + | | Authentication happens inline.
> + +-----------------+
> +
> +
> +Lookaside protocol offload
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL:
> +This extends librte_cryptodev to support the programming of IPsec
> +Security Association (SA) as part of a crypto session creation including
> +the definition. In addition to standard crypto processing, as defined by
> +the cryptodev, the security protocol processing is also offloaded to the
> +crypto device.
> +
> +Decryption: The packet is sent to the crypto device for security
> +protocol processing. The device will decrypt the packet and it will also
> +optionally remove additional security headers from the packet.
> +E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
> +will be removed from the packet and the decrypted packet may contain
> +plain data only.
> +
> +.. note::
> +
> + In case of IPSec the device may internally manage anti-replay etc.
> + It will provide a configuration option for anti-replay behavior i.e. to drop
> + the packets or pass them to driver with error flags set in descriptor.
> +
> +Encryption: The software will submit the packet to cryptodev as usual
> +for encryption, the hardware device in this case will also add the relevant
> +security protocol header along with encrypting the packet. The software
> +should make sure that the buffer has required head room and tail room
> +for any protocol header addition.
> +
> +.. note::
> +
> + In the case of IPSec, the seq number will be added to the packet,
> + It shall provide an indication when the sequence number is about to
> + overflow.
> +
> +.. code-block:: console
> +
> + Egress Data Path
> + |
> + +--------|--------+
> + | egress IPsec |
> + | | |
> + | +------V------+ |
> + | | SADB lookup | | <------ SA maps to cryptodev session
> + | +------|------+ |
> + | +------|------+ |
> + | | \--------------------\
> + | | Crypto | | | <- Crypto processing through
> + | | /----------------\ | inline crypto PMD
> + | +------|------+ | | |
> + +--------V--------+ | |
> + | | |
> + +--------V--------+ | | create <-- SA is added to hw
> + | L2 Stack | | | inline using existing create
> + +--------|--------+ | | session sym session APIs
> + | | | |
> + +--------V--------+ +---|---|----V---+
> + | | | \---/ | | <--- Add tunnel, ESP header etc
> + | NIC PMD | | INLINE | | header to packet.Packet
> + | | | CRYPTO PMD | | Encryption/Decryption and
> + +--------|--------+ +----------------+ Authentication happens
> + | inline.
> + +--------|--------+
> + | NIC |
> + +--------|--------+
> + V
> +
> +Device Features and Capabilities
> +---------------------------------
> +
> +Device Capabilities For Security Operations
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The device (crypto or ethernet) capabilities which support security operations,
> +are defined by the security action type, security protocol, protocol
> +capabilities and corresponding crypto capabilities for security. For the full
> +scope of the Security capability see definition of rte_security_capability
> +structure in the *DPDK API Reference*.
> +
> +.. code-block:: c
> +
> + struct rte_security_capability;
> +
> +Each driver (crypto or ethernet) defines its own private array of capabilities
> +for the operations it supports. Below is an example of the capabilities for a
> +PMD which supports the IPSec protocol.
> +
> +.. code-block:: c
> +
> + static const struct rte_security_capability pmd_security_capabilities[] = {
> + { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */
> + .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
> + .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
> + .ipsec = {
> + .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> + .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
> + .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS,
> + .options = { 0 }
> + },
> + .crypto_capabilities = pmd_capabilities
> + },
> + { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */
> + .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
> + .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
> + .ipsec = {
> + .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
> + .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
> + .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS,
> + .options = { 0 }
> + },
> + .crypto_capabilities = pmd_capabilities
> + },
> + {
> + .action = RTE_SECURITY_ACTION_TYPE_NONE
> + }
> + };
> + static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
> + { /* SHA1 HMAC */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
> + .auth = {
> + .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
> + .block_size = 64,
> + .key_size = {
> + .min = 64,
> + .max = 64,
> + .increment = 0
> + },
> + .digest_size = {
> + .min = 12,
> + .max = 12,
> + .increment = 0
> + },
> + .aad_size = { 0 },
> + .iv_size = { 0 }
> + }
> + }
> + },
> + { /* AES CBC */
> + .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
> + .sym = {
> + .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
> + .cipher = {
> + .algo = RTE_CRYPTO_CIPHER_AES_CBC,
> + .block_size = 16,
> + .key_size = {
> + .min = 16,
> + .max = 32,
> + .increment = 8
> + },
> + .iv_size = {
> + .min = 16,
> + .max = 16,
> + .increment = 0
> + }
> + }
> + }
> + }
> + }
> +
> +
> +Capabilities Discovery
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +Discovering the features and capabilities of a driver (crypto/ethernet)
> +is achieved through the ``rte_security_capabilities_get()`` function.
> +
> +.. code-block:: c
> +
> + const struct rte_security_capability *rte_security_capabilities_get(uint16_t id);
> +
> +This allows the user to query a specific driver and get all device
> +security capabilities. It returns an array of ``rte_security_capability`` structures
> +which contains all the capabilities for that device.
> +
> +Security Session Create/Free
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Security Sessions are created to store the immutable fields of a particular Security
> +Association for a particular protocol which is defined by a security session
> +configuration structure which is used in the operation processing of a packet flow.
> +Sessions are used to manage protocol specific information as well as crypto parameters.
> +Security sessions cache this immutable data in a optimal way for the underlying PMD
> +and this allows further acceleration of the offload of Crypto workloads.
> +
> +The Security framework provides APIs to create and free sessions for crypto/ethernet
> +devices, where sessions are mempool objects. It is the application's responsibility
> +to create and manage the session mempools. The mempool object size should be able to
> +accommodate the driver's private data of security session.
> +
> +Once the session mempools have been created, ``rte_security_session_create()``
> +is used to allocate and initialize a session for the required crypto/ethernet device.
> +
> +Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
> +security ops. This parameter can be retreived using the APIs
> +``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
> +(for ethernet port).
> +
> +Sessions already created can be updated with ``rte_security_session_update()``.
> +
> +When a session is no longer used, the user must call ``rte_security_session_destroy()``
> +to free the driver private session data and return the memory back to the mempool.
> +
> +For look aside protocol offload to hardware crypto device, the ``rte_crypto_op``
> +created by the application is attached to the security session by the API
> +``rte_security_attach_session()``.
> +
> +For Inline Crypto and Inline protocol offload, device specific defined metadata is
> +updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
> +``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
> +
> +Security session configuration
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +Security Session configuration structure is defined as ``rte_security_session_conf``
> +
> +.. code-block:: c
> +
> + struct rte_security_session_conf {
> + enum rte_security_session_action_type action_type;
> + /**< Type of action to be performed on the session */
> + enum rte_security_session_protocol protocol;
> + /**< Security protocol to be configured */
> + union {
> + struct rte_security_ipsec_xform ipsec;
> + struct rte_security_macsec_xform macsec;
> + };
> + /**< Configuration parameters for security session */
> + struct rte_crypto_sym_xform *crypto_xform;
> + /**< Security Session Crypto Transformations */
> + };
> +
> +The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
> +configuration. The ``rte_security_session_action_type`` struct is used to specify whether the
> +session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol
> +Offload.
> +
> +.. code-block:: c
> +
> + enum rte_security_session_action_type {
> + RTE_SECURITY_ACTION_TYPE_NONE,
> + /**< No security actions */
> + RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
> + /**< Crypto processing for security protocol is processed inline
> + * during transmission */
> + RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
> + /**< All security protocol processing is performed inline during
> + * transmission */
> + RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
> + /**< All security protocol processing including crypto is performed
> + * on a lookaside accelerator */
> + };
> +
> +The ``rte_security_session_protocol`` is defined as
> +
> +.. code-block:: c
> +
> + enum rte_security_session_protocol {
> + RTE_SECURITY_PROTOCOL_IPSEC,
> + /**< IPsec Protocol */
> + RTE_SECURITY_PROTOCOL_MACSEC,
> + /**< MACSec Protocol */
> + };
> +
> +Currently the library defines configuration parameters for IPSec only. For other
> +protocols like MACSec, structures and enums are defined as place holders which
> +will be updated in the future.
> +
> +IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``
> +
> +.. code-block:: c
> +
> + struct rte_security_ipsec_xform {
> + uint32_t spi;
> + /**< SA security parameter index */
> + uint32_t salt;
> + /**< SA salt */
> + struct rte_security_ipsec_sa_options options;
> + /**< various SA options */
> + enum rte_security_ipsec_sa_direction direction;
> + /**< IPSec SA Direction - Egress/Ingress */
> + enum rte_security_ipsec_sa_protocol proto;
> + /**< IPsec SA Protocol - AH/ESP */
> + enum rte_security_ipsec_sa_mode mode;
> + /**< IPsec SA Mode - transport/tunnel */
> + struct rte_security_ipsec_tunnel_param tunnel;
> + /**< Tunnel parameters, NULL for transport mode */
> + };
> +
> +
> +Security API
> +~~~~~~~~~~~~
> +
> +The rte_security Library API is described in the *DPDK API Reference* document.
> +
> +Flow based Security Session
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +In the case of NIC based offloads, the security session specified in the
> +'rte_flow_action_security' must be created on the same port as the
> +flow action that is being specified.
> +
> +The ingress/egress flow attribute should match that specified in the security
> +session if the security session supports the definition of the direction.
> +
> +Multiple flows can be configured to use the same security session. For
> +example if the security session specifies an egress IPsec SA, then multiple
> +flows can be specified to that SA. In the case of an ingress IPsec SA then
> +it is only valid to have a single flow to map to that security session.
> +
> +.. code-block:: console
> +
> + Configuration Path
> + |
> + +--------|--------+
> + | Add/Remove |
> + | IPsec SA | <------ Build security flow action of
> + | | | ipsec transform
> + |--------|--------|
> + |
> + +--------V--------+
> + | Flow API |
> + +--------|--------+
> + |
> + +--------V--------+
> + | |
> + | NIC PMD | <------ Add/Remove SA to/from hw context
> + | |
> + +--------|--------+
> + |
> + +--------|--------+
> + | HW ACCELERATED |
> + | NIC |
> + | |
> + +--------|--------+
> +
> +* Add/Delete SA flow:
> + To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
> + using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``.
> + Note that any rte_flow_items may be empty, which means it is not checked.
> +
> +.. code-block:: console
> +
> + In its most basic form, IPsec flow specification is as follows:
> + +-------+ +----------+ +--------+ +-----+
> + | Eth | -> | IP4/6 | -> | ESP | -> | END |
> + +-------+ +----------+ +--------+ +-----+
> +
> + However, the API can represent, IPsec crypto offload with any encapsulation:
> + +-------+ +--------+ +-----+
> + | Eth | -> ... -> | ESP | -> | END |
> + +-------+ +--------+ +-----+
Tested-by: Aviad Yehezkel <aviadye@mellanox.com>
next prev parent reply other threads:[~2017-10-15 12:47 UTC|newest]
Thread overview: 195+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 8:26 [dpdk-dev] [PATCH 00/11] introduce security offload library Akhil Goyal
2017-09-14 8:26 ` [dpdk-dev] [PATCH 01/11] lib/rte_security: add security library Akhil Goyal
2017-09-15 5:32 ` Hemant Agrawal
2017-09-17 13:31 ` Boris Pismenny
2017-09-20 11:35 ` Akhil Goyal
2017-09-18 13:13 ` Jerin Jacob
2017-09-22 11:55 ` Radu Nicolau
2017-09-14 8:26 ` [dpdk-dev] [PATCH 02/11] doc: add details of rte security Akhil Goyal
2017-09-18 11:13 ` Jerin Jacob
2017-09-20 10:59 ` Akhil Goyal
2017-09-18 15:38 ` Mcnamara, John
2017-09-20 11:00 ` Akhil Goyal
2017-09-14 8:26 ` [dpdk-dev] [PATCH 03/11] cryptodev: extend cryptodev to support security APIs Akhil Goyal
2017-09-14 8:26 ` [dpdk-dev] [PATCH 04/11] lib/librte_net: add ESP header to generic flow steering Akhil Goyal
2017-09-15 4:51 ` Hemant Agrawal
2017-09-17 7:19 ` Boris Pismenny
2017-09-14 8:26 ` [dpdk-dev] [PATCH 05/11] lib/librte_mbuf: add security crypto flags and mbuf fields Akhil Goyal
2017-09-18 7:54 ` Boris Pismenny
2017-09-20 9:43 ` Olivier MATZ
2017-09-26 10:19 ` Boris Pismenny
2017-09-14 8:26 ` [dpdk-dev] [PATCH 06/11] ethdev: extend ethdev to support security APIs Akhil Goyal
2017-09-17 13:45 ` Shahaf Shuler
2017-09-22 11:42 ` Radu Nicolau
2017-09-18 7:57 ` Jerin Jacob
2017-09-22 11:49 ` Radu Nicolau
2017-09-14 8:26 ` [dpdk-dev] [PATCH 07/11] ethdev: add rte flow action for crypto Akhil Goyal
2017-09-21 9:16 ` Jerin Jacob
2017-09-21 16:53 ` Boris Pismenny
2017-09-14 8:26 ` [dpdk-dev] [PATCH 08/11] mk: add rte security into build system Akhil Goyal
2017-09-14 8:26 ` [dpdk-dev] [PATCH 09/11] net/ixgbe: enable inline ipsec Akhil Goyal
2017-09-15 4:48 ` Hemant Agrawal
2017-09-15 13:14 ` Doherty, Declan
2017-09-14 8:26 ` [dpdk-dev] [PATCH 10/11] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-09-14 8:26 ` [dpdk-dev] [PATCH 11/11] examples/ipsec-secgw: add support for security offload Akhil Goyal
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 00/12] introduce security offload library Akhil Goyal
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 01/12] lib/rte_security: add security library Akhil Goyal
2017-10-05 15:32 ` De Lara Guarch, Pablo
2017-10-05 16:30 ` Ananyev, Konstantin
2017-10-06 18:11 ` Akhil Goyal
2017-10-09 13:42 ` Ananyev, Konstantin
2017-10-10 12:17 ` Akhil Goyal
2017-10-11 9:02 ` Ananyev, Konstantin
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 02/12] doc: add details of rte security Akhil Goyal
2017-10-03 15:56 ` Mcnamara, John
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 03/12] cryptodev: extend cryptodev to support security APIs Akhil Goyal
2017-10-05 8:49 ` De Lara Guarch, Pablo
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 04/12] lib/librte_net: add ESP header to generic flow steering Akhil Goyal
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 05/12] lib/librte_mbuf: add security crypto flags and mbuf fields Akhil Goyal
2017-10-05 8:54 ` De Lara Guarch, Pablo
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 06/12] ethdev: extend ethdev to support security APIs Akhil Goyal
2017-10-04 10:52 ` Shahaf Shuler
2017-10-06 16:31 ` Radu Nicolau
2017-10-05 18:01 ` Ananyev, Konstantin
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 07/12] ethdev: add rte flow action for crypto Akhil Goyal
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 08/12] doc: add details of rte_flow security actions Akhil Goyal
2017-10-03 15:38 ` Mcnamara, John
2017-10-03 15:39 ` Mcnamara, John
2017-10-05 15:34 ` De Lara Guarch, Pablo
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 09/12] mk: add rte security into build system Akhil Goyal
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 10/12] net/ixgbe: enable inline ipsec Akhil Goyal
2017-10-05 17:55 ` Ananyev, Konstantin
2017-10-06 9:17 ` Radu Nicolau
2017-10-06 18:33 ` Ananyev, Konstantin
2017-10-10 16:10 ` Radu Nicolau
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 11/12] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-10-05 9:13 ` De Lara Guarch, Pablo
2017-10-03 13:14 ` [dpdk-dev] [PATCH v2 12/12] examples/ipsec-secgw: add support for security offload Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 00/12] introduce security offload library Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 01/12] lib/rte_security: add security library Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 02/12] doc: add details of rte security Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 03/12] cryptodev: support security APIs Akhil Goyal
2017-10-10 13:43 ` De Lara Guarch, Pablo
2017-10-21 15:22 ` Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 04/12] net: add ESP header to generic flow steering Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 05/12] mbuf: add security crypto flags and mbuf fields Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 06/12] ethdev: support security APIs Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 07/12] ethdev: add rte flow action for crypto Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 08/12] doc: add details of rte_flow security actions Akhil Goyal
2017-10-12 13:41 ` Mcnamara, John
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 09/12] mk: add rte security into build system Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 10/12] net/ixgbe: enable inline ipsec Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 11/12] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-10-06 18:11 ` [dpdk-dev] [PATCH v3 12/12] examples/ipsec-secgw: add support for security offload Akhil Goyal
2017-10-09 13:49 ` [dpdk-dev] [PATCH v3 00/12] introduce security offload library Ananyev, Konstantin
2017-10-10 12:22 ` Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 " Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 01/12] lib/rte_security: add security library Akhil Goyal
2017-10-15 12:47 ` Aviad Yehezkel
2017-10-19 9:30 ` Ananyev, Konstantin
2017-10-21 15:54 ` Akhil Goyal
2017-10-20 9:37 ` Thomas Monjalon
2017-10-20 9:39 ` Thomas Monjalon
2017-10-21 19:46 ` Akhil Goyal
2017-10-21 19:45 ` Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 02/12] doc: add details of rte security Akhil Goyal
2017-10-15 12:47 ` Aviad Yehezkel [this message]
2017-10-20 9:41 ` Thomas Monjalon
2017-10-21 19:48 ` Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 03/12] cryptodev: support security APIs Akhil Goyal
2017-10-15 12:48 ` Aviad Yehezkel
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 04/12] net: add ESP header to generic flow steering Akhil Goyal
2017-10-15 12:48 ` Aviad Yehezkel
2017-10-20 10:15 ` Thomas Monjalon
2017-10-21 19:49 ` Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 05/12] mbuf: add security crypto flags and mbuf fields Akhil Goyal
2017-10-15 12:49 ` Aviad Yehezkel
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 06/12] ethdev: support security APIs Akhil Goyal
2017-10-15 12:49 ` Aviad Yehezkel
2017-10-15 13:13 ` Shahaf Shuler
2017-10-16 8:46 ` Nicolau, Radu
2017-10-19 9:23 ` Ananyev, Konstantin
2017-10-21 16:00 ` Akhil Goyal
2017-10-23 9:56 ` Ananyev, Konstantin
2017-10-23 13:08 ` Nicolau, Radu
2017-10-20 10:58 ` Thomas Monjalon
2017-10-21 19:50 ` Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 07/12] ethdev: add rte flow action for crypto Akhil Goyal
2017-10-15 12:49 ` Aviad Yehezkel
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 08/12] doc: add details of rte_flow security actions Akhil Goyal
2017-10-15 12:50 ` Aviad Yehezkel
2017-10-16 19:17 ` Mcnamara, John
2017-10-20 11:00 ` Thomas Monjalon
2017-10-21 19:50 ` Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 09/12] mk: add rte security into build system Akhil Goyal
2017-10-15 12:50 ` Aviad Yehezkel
2017-10-20 11:06 ` Thomas Monjalon
2017-10-21 19:44 ` Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 10/12] net/ixgbe: enable inline ipsec Akhil Goyal
2017-10-15 12:51 ` Aviad Yehezkel
2017-10-16 10:41 ` Thomas Monjalon
2017-10-18 21:29 ` Ananyev, Konstantin
2017-10-19 10:51 ` Radu Nicolau
2017-10-19 11:04 ` Ananyev, Konstantin
2017-10-19 11:57 ` Nicolau, Radu
2017-10-19 12:16 ` Ananyev, Konstantin
2017-10-19 12:29 ` Ananyev, Konstantin
2017-10-19 13:14 ` Radu Nicolau
2017-10-19 13:22 ` Ananyev, Konstantin
2017-10-19 14:19 ` Nicolau, Radu
2017-10-19 14:36 ` Ananyev, Konstantin
2017-10-19 13:09 ` Radu Nicolau
2017-10-19 9:04 ` Ananyev, Konstantin
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 11/12] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-10-14 22:17 ` [dpdk-dev] [PATCH v4 12/12] examples/ipsec-secgw: add support for security offload Akhil Goyal
2017-10-15 12:51 ` Aviad Yehezkel
2017-10-16 10:44 ` [dpdk-dev] [PATCH v4 00/12] introduce security offload library Thomas Monjalon
2017-10-20 9:32 ` Thomas Monjalon
2017-10-21 16:13 ` Akhil Goyal
2017-10-22 20:37 ` Akhil Goyal
2017-10-22 20:59 ` Thomas Monjalon
2017-10-23 11:44 ` Aviad Yehezkel
2017-10-24 9:41 ` Akhil Goyal
2017-10-24 9:52 ` Thomas Monjalon
2017-10-24 14:27 ` Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 00/11] " Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 01/11] lib/rte_security: add security library Akhil Goyal
2017-10-24 15:15 ` De Lara Guarch, Pablo
2017-10-25 11:06 ` Akhil Goyal
2017-10-24 20:47 ` Thomas Monjalon
2017-10-25 11:08 ` Akhil Goyal
2017-10-25 5:13 ` Hemant Agrawal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 02/11] doc: add details of rte security Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 03/11] cryptodev: support security APIs Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 04/11] net: add ESP header to generic flow steering Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 05/11] mbuf: add security crypto flags and mbuf fields Akhil Goyal
2017-10-25 9:38 ` Olivier MATZ
2017-10-25 12:05 ` Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 06/11] ethdev: support security APIs Akhil Goyal
2017-10-25 5:05 ` Hemant Agrawal
2017-10-25 7:01 ` Shahaf Shuler
2017-10-25 12:35 ` Aviad Yehezkel
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 07/11] ethdev: add rte flow action for crypto Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 08/11] mk: add rte security into build system Akhil Goyal
2017-10-24 20:48 ` Thomas Monjalon
2017-10-25 11:12 ` Akhil Goyal
2017-10-25 5:04 ` Hemant Agrawal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 09/11] net/ixgbe: enable inline ipsec Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 10/11] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-10-24 14:15 ` [dpdk-dev] [PATCH v5 11/11] examples/ipsec-secgw: add support for security offload Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 00/10] introduce security offload library Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 01/10] cryptodev: support security APIs Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 02/10] net: add ESP header to generic flow steering Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 03/10] mbuf: add security crypto flags and mbuf fields Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 04/10] ethdev: support security APIs Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 05/10] ethdev: add rte flow action for crypto Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 06/10] security: introduce security API and framework Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 07/10] doc: add details of rte security Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 08/10] net/ixgbe: enable inline ipsec Akhil Goyal
2017-10-26 7:09 ` David Marchand
2017-10-26 7:19 ` David Marchand
2017-11-01 19:58 ` Thomas Monjalon
2017-11-01 20:10 ` Ferruh Yigit
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 09/10] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-10-25 15:07 ` [dpdk-dev] [PATCH v6 10/10] examples/ipsec-secgw: add support for security offload Akhil Goyal
2017-10-26 1:16 ` [dpdk-dev] [PATCH v6 00/10] introduce security offload library Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f9b1446-d80b-3cf5-602e-032538456c9f@dev.mellanox.co.il \
--to=aviadye@dev.mellanox.co.il \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).