DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Awal, Mohammad Abdul" <mohammad.abdul.awal@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	"Jerin Jacob (jerin.jacob@caviumnetworks.com)"
	<jerin.jacob@caviumnetworks.com>,
	Narayana Prasad <narayanaprasad.athreya@caviumnetworks.com>
Subject: Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing
Date: Wed, 12 Sep 2018 18:09:49 +0000
Message-ID: <2601191342CEEE43887BDE71AB977258EA954E9D@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258EA954BAD@irsmsx105.ger.corp.intel.com>

Hi Anoob,

> 
> Hi Konstantin,
> Please see inline.
> 
> 
> This RFC introduces a new library within DPDK: librte_ipsec.
> The aim is to provide DPDK native high performance library for IPsec
> data-path processing.
> The library is supposed to utilize existing DPDK crypto-dev and
> security API to provide application with transparent IPsec processing API.
> The library is concentrated on data-path protocols processing (ESP and AH),
> IKE protocol(s) implementation is out of scope for that library.
> Though hook/callback mechanisms will be defined to allow integrate it
> with existing IKE implementations.
> Due to quite complex nature of IPsec protocol suite and variety of user
> requirements and usage scenarios a few API levels will be provided:
> 1) Security Association (SA-level) API
>      Operates at SA level, provides functions to:
>      - initialize/teardown SA object
>      - process inbound/outbound ESP/AH packets associated with the given SA
>        (decrypt/encrypt, authenticate, check integrity,
>         add/remove ESP/AH related headers and data, etc.).
> 2) Security Association Database (SAD) API
>      API to create/manage/destroy IPsec SAD.
>      While DPDK IPsec library plans to have its own implementation,
>      the intention is to keep it as independent from the other parts
>      of IPsec library as possible.
>      That is supposed to give users the ability to provide their own
>      implementation of the SAD compatible with the other parts of the
>      IPsec library.
> 3) IPsec Context (CTX) API
>      This is supposed to be a high-level API, where each IPsec CTX is an
>      abstraction of 'independent copy of the IPsec stack'.
>      CTX owns set of SAs, SADs and assigned to it crypto-dev queues, etc.
>      and provides:
>      - de-multiplexing stream of inbound packets to particular SAs and
>        further IPsec related processing.
>      - IPsec related processing for the outbound packets.
>      - SA add/delete/update functionality
> [Anoob]: Security Policy is an important aspect of IPsec. An IPsec
> library without Security Policy API would be incomplete. For inline
> protocol offload, the final SP-SA check(selector check) is the only
> IPsec part being done by ipsec-secgw now. Would make sense to add that
> also in the library.
> 
> You mean here, that we need some sort of SPD implementation, correct?
> [Anoob] Yes.

Ok, I see.
Our thought was that just something based on librte_acl would be enough here...
But if you think that a special defined SPD API (and implementation) is needed -
we can probably discuss it along with SAD API (#2 above).
Though if you'd like to start to work on RFC for it right-away - please feel free to do so :)

> 
> 
> 
> Current RFC concentrates on SA-level API only (1),
> detailed discussion for 2) and 3) will be subjects for separate RFC(s).
> 
> SA (low) level API
> ==================
> 
> API described below operates on SA level.
> It provides functionality that allows user for given SA to process
> inbound and outbound IPsec packets.
> To be more specific:
> - for inbound ESP/AH packets perform decryption, authentication,
>    integrity checking, remove ESP/AH related headers
> [Anoob] Anti-replay check would also be required.
> 
> Yep, anti-replay and ESN support is implied as part of "integrity checking".
> Probably I have to be more specific here.
> [Anoob] This is fine.
> 
> 
> 
> - for outbound packets perform payload encryption, attach ICV,
>    update/add IP headers, add ESP/AH headers/trailers,
>    setup related mbuf felids (ol_flags, tx_offloads, etc.).
> [Anoob] Do we have any plans to handle ESN expiry? Some means to
> initiate an IKE renegotiation? I'm assuming application won't be aware
> of the sequence numbers, in this case.
> [Anoob] What is your plan with events like ESN expiry? IPsec spec talks about byte and time expiry as well.

At current moment, for SA level: rte_ipsec_crypto_prepare()/rte_ipsec_inline_process() will set rte_errno
to special value (EOVERFLOW) to signal upper layer that limit is reached.
Upper layer can decide to start re-negotiation, or just destroy an SA.
 
Future plans for IPsec Context (CTX) API (#3 above):
Introduce a special function, something like:
rte_ipsec_get_expired(rte_ipsec_ctx *ctx, rte_ipsec_sa *expired_sa[], uint32_t num);
It would return up-to *num* of SAs for given ipsec context, that are expired/limit reached.
Then upper layer again might decide for each SA should renegotiation be started,
or just wipe given SA.
It would be upper layer responsibility to call this function periodically.
 
> 
> 
> - initialize/un-initialize given SA based on user provided parameters.
> 
> Processed inbound/outbound packets could be grouped by user provided
> flow id (opaque 64-bit number associated by user with given SA).
> 
> SA-level API is based on top of crypto-dev/security API and relies on them
> to perform actual cipher and integrity checking.
> Due to the nature of crypto-dev API (enqueue/deque model) we use
> asynchronous API for IPsec packets destined to be processed
> by crypto-device:
> rte_ipsec_crypto_prepare()->rte_cryptodev_enqueue_burst()->
> rte_cryptodev_dequeue_burst()->rte_ipsec_crypto_process().
> Though for packets destined for inline processing no extra overhead
> is required and simple and synchronous API: rte_ipsec_inline_process()
> is introduced for that case.
> [Anoob] The API should include event-delivery as a crypto-op completion
> mechanism as well. The application could configure the event crypto
> adapter and then enqueue and dequeue to crypto device using events (via
> event dev).
> 
> Not sure what particular extra API you think is required here?
> As I understand in both cases (with or without event crypto-adapter) we still have to:
>  1) fill crypto-op properly
>  2) enqueue it to crypto-dev (via eventdev or directly)
> 3)  receive processed by crypto-dev crypto-op (either via eventdev or directly)
> 4) check crypto-op status, do further post-processing if any
> 
> So #1 and #4 (SA-level API respnibility) remain the same for both cases.
> [Anoob] rte_ipsec_inline_process works on packets not events. We might need a similar API which processes events.

Ok, I still don't get you here.
Could you specify what exactly function you'd like to add to the API here with parameter list
and brief behavior description? 

> 
> The following functionality:
>    - match inbound/outbound packets to particular SA
>    - manage crypto/security devices
>    - provide SAD/SPD related functionality
>    - determine what crypto/security device has to be used
>      for given packet(s)
> is out of scope for SA-level API.
> 
> Below is the brief (and simplified) overview of expected SA-level
> API usage.
> 
> /* allocate and initialize SA */
> size_t sz = rte_ipsec_sa_size();
> struct rte_ipsec_sa *sa = rte_malloc(sz);
> struct rte_ipsec_sa_prm prm;
> /* fill prm */
> rc = rte_ipsec_sa_init(sa, &prm);
> if (rc != 0) { /*handle error */}
> .....
> 
> /* process inbound/outbound IPsec packets that belongs to given SA */
> 
> /* inline IPsec processing was done for these packets */
> if (use_inline_ipsec)
>         n = rte_ipsec_inline_process(sa, pkts, nb_pkts);
> /* use crypto-device to process the packets */
> else {
>       struct rte_crypto_op *cop[nb_pkts];
>       struct rte_ipsec_group grp[nb_pkts];
> 
>        ....
>       /* prepare crypto ops */
>       n = rte_ipsec_crypto_prepare(sa, pkts, cops, nb_pkts);
>       /* enqueue crypto ops to related crypto-dev */
>       n =  rte_cryptodev_enqueue_burst(..., cops, n);
>       if (n != nb_pkts) { /*handle failed packets */}
>       /* dequeue finished crypto ops from related crypto-dev */
>       n = rte_cryptodev_dequeue_burst(..., cops, nb_pkts);
>       /* finish IPsec processing for associated packets */
>       n = rte_ipsec_crypto_process(cop, pkts, grp, n);
> [Anoob] Does the SA based grouping apply to both inbound and outbound?
> 
> Yes, the plan is to have it available for both cases.
> [Anoob] On the inbound, shouldn't the packets be grouped+ordered based on inner L3+inner L4?

I think that's up to the user decide based on what criteria wants to group it and does he wants
to do any grouping at all.
That's why flowid is user-defined and totally transparent to the lib.

> 
> 
> 
>       /* now we have <n> group of packets grouped by SA flow id  */
>      ....
>   }
> ...
> 
> /* uninit given SA */
> rte_ipsec_sa_fini(sa);
> 
> Planned scope for 18.11:
> ========================
> 
> - SA-level API definition
> - ESP tunnel mode support (both IPv4/IPv6)
> - Supported algorithms: AES-CBC, AES-GCM, HMAC-SHA1, NULL.
> - UT
> [Anoob] What is UT?
> 
> Unit-Test
> 
> 
> Note: Still WIP, so not all planned for 18.11 functionality is in place.
> 
> Post 18.11:
> ===========
> - ESP transport mode support (both IPv4/IPv6)
> - update examples/ipsec-secgw to use librte_ipsec
> - SAD and high-level API definition and implementation
> 
> 
> Signed-off-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
>   config/common_base                     |   5 +
>   lib/Makefile                           |   2 +
>   lib/librte_ipsec/Makefile              |  24 +
>   lib/librte_ipsec/meson.build           |  10 +
>   lib/librte_ipsec/pad.h                 |  45 ++
>   lib/librte_ipsec/rte_ipsec.h           | 245 +++++++++
>   lib/librte_ipsec/rte_ipsec_version.map |  13 +
>   lib/librte_ipsec/sa.c                  | 921 +++++++++++++++++++++++++++++++++
>   lib/librte_net/rte_esp.h               |  10 +-
>   lib/meson.build                        |   2 +
>   mk/rte.app.mk                          |   2 +
>   11 files changed, 1278 insertions(+), 1 deletion(-)
>   create mode 100644 lib/librte_ipsec/Makefile
>   create mode 100644 lib/librte_ipsec/meson.build
>   create mode 100644 lib/librte_ipsec/pad.h
>   create mode 100644 lib/librte_ipsec/rte_ipsec.h
>   create mode 100644 lib/librte_ipsec/rte_ipsec_version.map
>   create mode 100644 lib/librte_ipsec/sa.c
> <snip>
> +static inline uint16_t
> +esp_outb_tun_prepare(struct rte_ipsec_sa *sa, struct rte_mbuf *mb[],
> +       struct rte_crypto_op *cop[], uint16_t num)
> +{
> +       int32_t rc;
> +       uint32_t i, n;
> +       union sym_op_data icv;
> +
> +       n = esn_outb_check_sqn(sa, num);
> +
> +       for (i = 0; i != n; i++) {
> +
> +               sa->sqn++;
> [Anoob] Shouldn't this be done atomically?
> 
> If we want to have MT-safe API for SA-datapath API, then yes.
> Though it would make things more complicated here, especially for inbound with anti-replay support.
> I think it is doable (spin-lock?), but would cause extra overhead and complexity.
> Right now I am not sure it really worth it - comments/suggestions are welcome.
> What probably could be a good compromise - runtime decision per SA basis (at sa_init()),
> do we need an ST or MT behavior for given SA.
> [Anoob] Going with single thread approach would significantly limit the scope of this library. Single thread approach would mean
> one SA on one core. This would not work on practical cases.
> Suppose we have two flows which are supposed to use the same SA. With RSS, these flows could end up on different cores. Now
> only one core would be able to process, as SA will not be shared. We have the same problem in ipsec-secgw too.

Just for my curiosity - how do you plan to use RSS for ipsec packet distribution?
Do you foresee a common situation when there would be packets that belongs to the same SA
(same SPI) but with multiple source(destination) IP addresses?
If so, probably some examples would be helpful.
I think IPsec RFCs doesn't prevent such situation, but AFAIK the most common case - single source/destination IPs for the same SPI.

Anyway, let's pretend we found some smart way to distribute inbound packets for the same SA to multiple HW queues/CPU cores.
To make ipsec processing for such case to work correctly just atomicity on check/update segn/replay_window is not enough.
I think it would require some extra synchronization:  
make sure that we do final packet processing (seq check/update) at the same order as we received the packets
(packets entered ipsec processing).  
I don't really like to introduce such heavy mechanisms on SA level,  after all it supposed to be light and simple.
Though we plan CTX level API to support such scenario.
What I think would be useful addition for SA level API - have an ability to do one update seqn/replay_window and multiple checks concurrently.

> In case of ingress also, the same problem exists. We will not be able to use RSS and spread the traffic to multiple cores. Considering
> IPsec being CPU intensive, this would limit the net output of the chip.

That's true - but from other side implementation can offload heavy part
(encrypt/decrypt, auth) to special HW (cryptodev).
In that case single core might be enough for SA and extra synchronization would just slowdown things.
That's why I think it should be configurable  what behavior (ST or MT) to use. 

Konstantin

  parent reply	other threads:[~2018-09-12 18:09 UTC|newest]

Thread overview: 194+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-24 16:53 Konstantin Ananyev
2018-09-03 12:41 ` Joseph, Anoob
2018-09-03 18:21   ` Ananyev, Konstantin
2018-09-05 14:39     ` Joseph, Anoob
     [not found]       ` <2601191342CEEE43887BDE71AB977258EA954BAD@irsmsx105.ger.corp.intel.com>
2018-09-12 18:09         ` Ananyev, Konstantin [this message]
2018-09-15 17:06           ` Joseph, Anoob
2018-09-16 10:56             ` Jerin Jacob
2018-09-17 18:12               ` Ananyev, Konstantin
2018-09-18 12:42                 ` Ananyev, Konstantin
2018-09-20 14:26                   ` Akhil Goyal
2018-09-24 10:51                     ` Ananyev, Konstantin
2018-09-25  7:48                       ` Akhil Goyal
2018-09-30 21:00                         ` Ananyev, Konstantin
2018-10-01 12:49                           ` Akhil Goyal
2018-10-02 23:24                             ` Ananyev, Konstantin
2018-09-18 17:54                 ` Jerin Jacob
2018-09-24  8:45                   ` Ananyev, Konstantin
2018-09-26 18:02                     ` Jerin Jacob
2018-10-02 23:56                       ` Ananyev, Konstantin
2018-10-03  9:37                         ` Jerin Jacob
2018-10-09 18:24                           ` Ananyev, Konstantin
2018-09-17 10:36             ` Ananyev, Konstantin
2018-09-17 14:41               ` Joseph, Anoob
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 0/9] " Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 1/9] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 2/9] security: add opaque userdata pointer into security session Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 3/9] net: add ESP trailer structure definition Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 4/9] lib: introduce ipsec library Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API Konstantin Ananyev
2018-10-18 17:37   ` Jerin Jacob
2018-10-21 22:01     ` Ananyev, Konstantin
2018-10-24 12:03       ` Jerin Jacob
2018-10-28 20:37         ` Ananyev, Konstantin
2018-10-29 10:19           ` Jerin Jacob
2018-10-30 13:53             ` Ananyev, Konstantin
2018-10-31  6:37               ` Jerin Jacob
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 6/9] ipsec: implement " Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 7/9] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 8/9] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2018-10-09 18:23 ` [dpdk-dev] [RFC v2 9/9] test/ipsec: introduce functional test Konstantin Ananyev
2018-11-15 23:53 ` [dpdk-dev] [PATCH 0/9] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2018-11-15 23:53 ` [dpdk-dev] [PATCH 1/9] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2018-11-16 10:23   ` Mohammad Abdul Awal
2018-11-30 16:45   ` [dpdk-dev] [PATCH v2 0/9] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2018-11-30 16:45   ` [dpdk-dev] [PATCH v2 1/9] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2018-12-04 13:13     ` Mohammad Abdul Awal
2018-12-04 15:32       ` Trahe, Fiona
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 0/9] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 1/9] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2018-12-11 17:24       ` Doherty, Declan
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 01/10] " Konstantin Ananyev
2018-12-19  9:26         ` Akhil Goyal
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-11  1:09             ` Xu, Yanjie
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-04  0:25             ` Stephen Hemminger
2019-01-04  9:29               ` Ananyev, Konstantin
2019-01-09 23:41                 ` Thomas Monjalon
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-10 14:25               ` Thomas Monjalon
2019-01-10 14:40                 ` De Lara Guarch, Pablo
2019-01-10 14:52                 ` Ananyev, Konstantin
2019-01-10 14:54                   ` Thomas Monjalon
2019-01-10 14:58                     ` Ananyev, Konstantin
2019-01-10 15:00                       ` Akhil Goyal
2019-01-10 15:09                         ` Akhil Goyal
2019-01-10 14:51               ` Akhil Goyal
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 0/9] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-10 23:59                 ` De Lara Guarch, Pablo
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 1/9] security: add opaque userdata pointer into security session Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 2/9] net: add ESP trailer structure definition Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 3/9] lib: introduce ipsec library Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 4/9] ipsec: add SA data-path API Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 5/9] ipsec: implement " Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 6/9] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 7/9] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 8/9] test/ipsec: introduce functional test Konstantin Ananyev
2019-01-10 21:06               ` [dpdk-dev] [PATCH v8 9/9] doc: add IPsec library guide Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 02/10] security: add opaque userdata pointer into security session Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 03/10] net: add ESP trailer structure definition Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 04/10] lib: introduce ipsec library Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 05/10] ipsec: add SA data-path API Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 06/10] ipsec: implement " Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 07/10] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 08/10] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 09/10] test/ipsec: introduce functional test Konstantin Ananyev
2019-01-10 14:20             ` [dpdk-dev] [PATCH v7 10/10] doc: add IPsec library guide Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 02/10] security: add opaque userdata pointer into security session Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 03/10] net: add ESP trailer structure definition Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 04/10] lib: introduce ipsec library Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 05/10] ipsec: add SA data-path API Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 06/10] ipsec: implement " Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 07/10] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 08/10] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 09/10] test/ipsec: introduce functional test Konstantin Ananyev
2019-01-03 20:16           ` [dpdk-dev] [PATCH v6 10/10] doc: add IPsec library guide Konstantin Ananyev
2019-01-10  8:35             ` Thomas Monjalon
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 02/10] security: add opaque userdata pointer into security session Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 03/10] net: add ESP trailer structure definition Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 04/10] lib: introduce ipsec library Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 05/10] ipsec: add SA data-path API Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 06/10] ipsec: implement " Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 07/10] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 08/10] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 09/10] test/ipsec: introduce functional test Konstantin Ananyev
2018-12-28 15:17         ` [dpdk-dev] [PATCH v5 10/10] doc: add IPsec library guide Konstantin Ananyev
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 02/10] security: add opaque userdata pointer into security session Konstantin Ananyev
2018-12-19  9:26         ` Akhil Goyal
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 03/10] net: add ESP trailer structure definition Konstantin Ananyev
2018-12-19  9:32         ` Akhil Goyal
2018-12-27 10:13           ` Olivier Matz
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 04/10] lib: introduce ipsec library Konstantin Ananyev
2018-12-19 12:08         ` Akhil Goyal
2018-12-19 12:39           ` Thomas Monjalon
2018-12-20 14:06           ` Ananyev, Konstantin
2018-12-20 14:14             ` Thomas Monjalon
2018-12-20 14:26               ` Ananyev, Konstantin
2018-12-20 18:17             ` Ananyev, Konstantin
2018-12-21 11:57               ` Akhil Goyal
2018-12-21 11:53             ` Akhil Goyal
2018-12-21 12:41               ` Ananyev, Konstantin
2018-12-21 12:54                 ` Ananyev, Konstantin
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 05/10] ipsec: add SA data-path API Konstantin Ananyev
2018-12-19 13:04         ` Akhil Goyal
2018-12-20 10:17           ` Ananyev, Konstantin
2018-12-21 12:14             ` Akhil Goyal
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 06/10] ipsec: implement " Konstantin Ananyev
2018-12-19 15:32         ` Akhil Goyal
2018-12-20 12:56           ` Ananyev, Konstantin
2018-12-21 12:36             ` Akhil Goyal
2018-12-21 14:27               ` Ananyev, Konstantin
2018-12-21 14:39                 ` Thomas Monjalon
2018-12-21 14:51                 ` Akhil Goyal
2018-12-21 15:16                   ` Ananyev, Konstantin
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 07/10] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 08/10] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2018-12-19 15:46         ` Akhil Goyal
2018-12-20 13:00           ` Ananyev, Konstantin
2018-12-21 12:37             ` Akhil Goyal
2018-12-14 16:23       ` [dpdk-dev] [PATCH v4 09/10] test/ipsec: introduce functional test Konstantin Ananyev
2018-12-19 15:53         ` Akhil Goyal
2018-12-20 13:03           ` Ananyev, Konstantin
2018-12-21 12:41             ` Akhil Goyal
2018-12-14 16:27       ` [dpdk-dev] [PATCH v4 10/10] doc: add IPsec library guide Konstantin Ananyev
2018-12-19  3:46         ` Thomas Monjalon
2018-12-19 16:01         ` Akhil Goyal
2018-12-20 13:06           ` Ananyev, Konstantin
2018-12-21 12:58             ` Akhil Goyal
2018-12-14 16:29       ` [dpdk-dev] [PATCH v4 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2018-12-21 13:32         ` Akhil Goyal
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 2/9] security: add opaque userdata pointer into security session Konstantin Ananyev
2018-12-11 17:25       ` Doherty, Declan
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 3/9] net: add ESP trailer structure definition Konstantin Ananyev
2018-12-11 17:25       ` Doherty, Declan
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 4/9] lib: introduce ipsec library Konstantin Ananyev
2018-12-11 17:25       ` Doherty, Declan
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 5/9] ipsec: add SA data-path API Konstantin Ananyev
2018-12-11 17:25       ` Doherty, Declan
2018-12-12  7:37         ` Ananyev, Konstantin
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 6/9] ipsec: implement " Konstantin Ananyev
2018-12-12 17:47       ` Doherty, Declan
2018-12-13 11:21         ` Ananyev, Konstantin
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 7/9] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2018-12-13 12:14       ` Doherty, Declan
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 8/9] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2018-12-13 12:14       ` Doherty, Declan
2018-12-06 15:38     ` [dpdk-dev] [PATCH v3 9/9] test/ipsec: introduce functional test Konstantin Ananyev
2018-12-13 12:54       ` Doherty, Declan
2018-11-30 16:45   ` [dpdk-dev] [PATCH v2 2/9] security: add opaque userdata pointer into security session Konstantin Ananyev
2018-12-04 13:13     ` Mohammad Abdul Awal
2018-11-30 16:46   ` [dpdk-dev] [PATCH v2 3/9] net: add ESP trailer structure definition Konstantin Ananyev
2018-12-04 13:12     ` Mohammad Abdul Awal
2018-11-30 16:46   ` [dpdk-dev] [PATCH v2 4/9] lib: introduce ipsec library Konstantin Ananyev
2018-11-30 16:46   ` [dpdk-dev] [PATCH v2 5/9] ipsec: add SA data-path API Konstantin Ananyev
2018-11-30 16:46   ` [dpdk-dev] [PATCH v2 6/9] ipsec: implement " Konstantin Ananyev
2018-11-30 16:46   ` [dpdk-dev] [PATCH v2 7/9] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2018-11-30 16:46   ` [dpdk-dev] [PATCH v2 8/9] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2018-11-30 16:46   ` [dpdk-dev] [PATCH v2 9/9] test/ipsec: introduce functional test Konstantin Ananyev
2018-11-15 23:53 ` [dpdk-dev] [PATCH 2/9] security: add opaque userdata pointer into security session Konstantin Ananyev
2018-11-16 10:24   ` Mohammad Abdul Awal
2018-11-15 23:53 ` [dpdk-dev] [PATCH 3/9] net: add ESP trailer structure definition Konstantin Ananyev
2018-11-16 10:22   ` Mohammad Abdul Awal
2018-11-15 23:53 ` [dpdk-dev] [PATCH 4/9] lib: introduce ipsec library Konstantin Ananyev
2018-11-15 23:53 ` [dpdk-dev] [PATCH 5/9] ipsec: add SA data-path API Konstantin Ananyev
2018-11-15 23:53 ` [dpdk-dev] [PATCH 6/9] ipsec: implement " Konstantin Ananyev
2018-11-20  1:03   ` Zhang, Qi Z
2018-11-20  9:44     ` Ananyev, Konstantin
2018-11-20 10:02       ` Ananyev, Konstantin
2018-11-15 23:53 ` [dpdk-dev] [PATCH 7/9] ipsec: rework SA replay window/SQN for MT environment Konstantin Ananyev
2018-11-15 23:53 ` [dpdk-dev] [PATCH 8/9] ipsec: helper functions to group completed crypto-ops Konstantin Ananyev
2018-11-15 23:53 ` [dpdk-dev] [PATCH 9/9] test/ipsec: introduce functional test Konstantin Ananyev

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=2601191342CEEE43887BDE71AB977258EA954E9D@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=Anoob.Joseph@caviumnetworks.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=mohammad.abdul.awal@intel.com \
    --cc=narayanaprasad.athreya@caviumnetworks.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git