DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: <dev@dpdk.org>, <borisp@mellanox.com>, <declan.doherty@intel.com>
Cc: <radu.nicolau@intel.com>, <aviadye@mellanox.com>,
	<sandeep.malik@nxp.com>,  <hemant.agrawal@nxp.com>,
	<pablo.de.lara.guarch@intel.com>,
	Akhil Goyal <akhil.goyal@nxp.com>
Subject: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload
Date: Tue, 25 Jul 2017 16:51:52 +0530	[thread overview]
Message-ID: <20170725112153.29699-1-akhil.goyal@nxp.com> (raw)
In-Reply-To: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com>

Below is a counter proposal for the RFC sent by Boris.
If we find some consensus, we can have implementation for this proposal in a few weeks.

The proposal is largely inline with the thoughts from Declan with a few exceptions.
Here we are proposing a security framework which can be used both by crypto drivers
and the hw offloaded NIC to showcase the protocol offload support as well as inline
ipsec in hw offloaded NIC.

The placement of the rte_security.X can either be a separate library like
lib/librte_security/ or it can be taken as an extension to the lib/librte_cryptodev/.
The reason for placing this in the cryptodev is that we are referring to some
crypto enums and the APIs look similar to that of cryptodev.

Here we propose that the application may be able to configure either NIC or
crypto PMD to perform IPSec and other security operations.
This is configured using the API

int
rte_security_configure(uint16_t dev_id, char *dev_name);

This API take dev_id and dev_name to identify which device needs to perform security
operation. Once the device is enabled for Security operations, the application can
create and initialize the session for the enabled device.

struct rte_security_session *
rte_security_session_create(struct rte_mempool *mempool);

int
rte_security_session_init(uint16_t dev_id, char *dev_name,
                          struct rte_security_session *sess,
                          struct rte_security_sess_conf *conf,
                          struct rte_mempool *mempool);

These two APIs are similar to the rte_cryptodev_sym_session_create and
rte_cryptodev_sym_session_init respectively, except that rte_security_session_init
takes device name also to identify between the NIC(IPSEC inline or full offload)
or crypto(look aside protocol offload).

These sessions can be cleared and freed with the APIs

int
rte_security_session_clear(uint8_t dev_id, char *dev_name,
                           struct rte_security_session *sess);
int
rte_security_session_free(struct rte_security_session *sess);

The details for various structures used are mentioned in the below patch.
These are very similar to what Declan proposed with a few additions.
This can be updated further for other security protocols like MACSec and DTLS

Now, after the application configures the session using above APIs, it needs to
attach the  session with the crypto_op in case the session is configured for
crypto look aside protocol offload. For IPSec inline/ full protocol offload
using NIC, the mbuf ol_flags can be set as per the RFC suggested by Boris.

Configuration path for both crypto and NIC can be illustrated as below

  Configuration Path                       Configuration Path
       for NIC                                  for Crypto
          |                                         |
 +--------|--------+                       +--------|--------+
 |    Add/Remove   |                       |   Add/Remove    |
 |     IPsec SA    |                       |    IPSec SA     |
 |        |        |                       |        |        |
 |--------|--------|                       +--------|--------+
          |                                         |
 +--------V--------+                                |
 |   Flow API      |                                |
 +--------|--------+                                |
          |                                         |
 +--------V--------+                       +--------V--------+
 |                 |                       |                 |
 |     NIC PMD     |                       |    Crypto PMD   |
 |                 |                       |                 |
 +--------|--------+                       +--------|--------+
          |                                         |
 +--------|--------+                       +--------|--------+
 |  HW ACCELERATED |                       |     HW Crypto   |
 |        NIC      |                       |  Protocol Aware |
 |                 |                       |     Device      |
 +--------|--------+                       +--------|--------+


Now the application(ipsec-secgw) have 4 paths to decide for the data path.
1. Non-protocol offload (currently implemented)
2. IPSec inline(only crypto operations using NIC)
3. full protocol offload(crypto operations along with all the IPsec header
   and trailer processing using NIC)
4. look aside protocol offload(single-pass encryption and authentication with
   additional levels of protocol processing offload using crypto device)

The application can decide using the below action types
enum rte_security_session_action_type {
        RTE_SECURITY_SESS_ETH_INLINE_CRYPTO,
        /**< Crypto operations are performed by Network interface */
        RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD,
        /**< Crypto operations with protocol support are performed
         * by Network/ethernet device.
         */
        RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD,
        /**< Crypto operations with protocol support are performed
         * by Crypto device.
         */
        RTE_SECURITY_SESS_NONE
	/**< Non protocol offload. Application need to manage everything */
};


 Egress Data Path

For ETH_INLINE_CRYPTO                  For CRYPTO_PROTO_OFFLOAD
         |                                         |
+--------|--------+                    +-----------|-----------+
|  egress IPsec   |                    | Plain packet from NIC |
|        |        |                    |           |           |
| +------V------+ |                    |  +--------V--------+  |
| | SABD lookup | |                    |  |    SA lookup    |  |
| +------|------+ |                    |  +--------|--------+  |
| +------V------+ |                    |  +--------V--------+  |
| |   Tunnel    | |                    |  |  session attach |  |
| +------|------+ |                    |  +--------|--------+  |   +------------+
| +------V------+ |                    |  +--------V--------+  |   | Hw crypto  |
| |     ESP     | |                    |  |Enqueue to crypto|------>  Device    |      <--- Headers are added by the HW device.
| |             | |                    |  |     Device      |  |   |            |
| +------|------+ |                    |  +-----------------+  |   +-----|------+
+--------V--------+                    |  +-----------------+  |         |
         |                             |  |  Dequeue from   |<-----------+   
+--------V--------+                    |  |  Crypto Device  |  |
|    L2 Stack     |                    |  +--------|--------+  |
+--------|--------+                    |  +--------V--------+  |
         |                             |  |   L2 Stack      |  |
+--------V--------+                    |  +--------|--------+  |
|                 |                    +-----------|-----------+
|     NIC PMD     |                                |
|                 |                    +-----------V-----------+
+--------|--------+                    |        NIC PMD        |
         |                             |   (packet sent out)   |
+--------|--------+                    +-----------|-----------+
|  HW ACCELERATED |   
|        NIC      |          
|                 |
+--------|--------+

   Ingress Data Path

For ETH_INLINE_CRYPTO                  For CRYPTO_PROTO_OFFLOAD
         |                                         |
+--------|--------+                    +-----------|-----------+
|  Ingress ipsec  |                    | Encap packet from NIC |
|        |        |                    |           |           |
| +------V------+ |                    |  +--------V--------+  |
| | HW ACC NIC  | |                    |  |     SA lookup   |  |
| +------|------+ |                    |  +--------|--------+  |
| +------V------+ |                    |  +--------V--------+  |
| |validate ESP | |                    |  |  session attach |  |
| +------|------+ |                    |  +--------|--------+  |   +------------+
| +------V------+ |                    |  +--------V--------+  |   | Hw crypto  |
| |Remove  ESP  | |                    |  |Enqueue to crypto|------>  Device    |      <--- Headers are removed by the HW device.
| | and Tunnel  | |                    |  |     Device      |  |   |            |
| +------|------+ |                    |  +-----------------+  |   +-----|------+
+--------V--------+                    |  +-----------------+  |         |
         |                             |  |  Dequeue from   |<-----------+   
+--------V----------+                  |  |  Crypto Device  |  |
|Plain packet to App|                  |  +--------|--------+  |
+--------|----------+                  |  +--------V--------+  |
                                       |  |Plain packet to  |  |
                                       |  |    app          |  |
                                       |  +-----------------+  |
                                       +-----------------------+


Akhil Goyal (1):
  RFC: rte_security: proposal

 lib/librte_security/rte_security.h | 405 +++++++++++++++++++++++++++++++++++++
 1 file changed, 405 insertions(+)
 create mode 100644 lib/librte_security/rte_security.h

-- 
2.9.3

  reply	other threads:[~2017-07-25 11:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10  7:35 [dpdk-dev] [RFC 0/7] ipsec inline Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 1/7] ethdev: add device ipsec encrypt/decrypt capability flags Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 2/7] ethdev: Add ESP header to generic flow steering Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 3/7] ethdev: add rte flow action for crypto Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 4/7] cryptodev: add ipsec xform Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 5/7] mbuf: Add IPsec crypto flags Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 6/7] mbuf: Added next_esp_proto field Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 7/7] example/ipsec_gw: Support SA offload in datapath Boris Pismenny
2017-07-11 17:06 ` [dpdk-dev] [RFC 0/7] ipsec inline Declan Doherty
2017-07-12 14:08   ` Boris Pismenny
2017-07-14 11:12   ` Akhil Goyal
2017-07-25 11:21     ` Akhil Goyal [this message]
2017-07-25 11:21       ` [dpdk-dev] [RFC PATCH 1/1] rte_security: proposal Akhil Goyal
2017-07-26 13:46       ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Declan Doherty
2017-08-02 13:16         ` Hemant Agrawal
2017-08-03 11:25           ` Akhil Goyal
2017-08-15  6:35       ` [dpdk-dev] [RFC PATCH v2 0/4] " Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 1/4] rte_security: API definitions Akhil Goyal
2017-08-15 11:04           ` Radu Nicolau
2017-08-16  7:39             ` Akhil Goyal
2017-08-16 15:40               ` Hemant Agrawal
2017-08-18  9:16                 ` Thomas Monjalon
2017-08-18 12:20                   ` Hemant Agrawal
2017-08-21 10:32                   ` Boris Pismenny
2017-08-21 10:54                     ` Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 2/4] cryptodev: entend cryptodev to support security APIs Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 3/4] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 4/4] example/ipsec-secgw: add support for offloading crypto op Akhil Goyal
2017-08-29 14:49       ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Thomas Monjalon
2017-08-31  9:37         ` Akhil Goyal
2017-08-31 10:06           ` Thomas Monjalon
2017-08-31 10:52             ` Akhil Goyal
2017-08-31 13:14               ` Thomas Monjalon
2017-08-31 14:09                 ` Radu Nicolau
2017-09-06 15:53                   ` Jerin Jacob
2017-09-08 11:12                     ` Akhil Goyal
2017-09-11 18:10                       ` Jerin Jacob

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=20170725112153.29699-1-akhil.goyal@nxp.com \
    --to=akhil.goyal@nxp.com \
    --cc=aviadye@mellanox.com \
    --cc=borisp@mellanox.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=radu.nicolau@intel.com \
    --cc=sandeep.malik@nxp.com \
    /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).