From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Awal, Mohammad Abdul" <mohammad.abdul.awal@intel.com>,
"Joseph, Anoob" <Anoob.Joseph@cavium.com>,
"Athreya, Narayana Prasad" <NarayanaPrasad.Athreya@cavium.com>
Subject: Re: [dpdk-dev] [RFC v2 5/9] ipsec: add SA data-path API
Date: Sun, 21 Oct 2018 22:01:48 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772580102FEA53E@IRSMSX106.ger.corp.intel.com> (raw)
In-Reply-To: <20181018173745.GA14157@jerin>
Hi Jerin,
>
> Hi Konstantin,
>
> Overall it looks good, but some comments on event mode integration in
> performance effective way.
>
> >
> > Introduce Security Association (SA-level) data-path 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.).
> >
> > Signed-off-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> > lib/librte_ipsec/Makefile | 2 +
> > lib/librte_ipsec/meson.build | 4 +-
> > lib/librte_ipsec/rte_ipsec.h | 154 +++++++++++++++++++++++++++++++++
> > lib/librte_ipsec/rte_ipsec_version.map | 3 +
> > lib/librte_ipsec/sa.c | 98 ++++++++++++++++++++-
> > lib/librte_ipsec/sa.h | 3 +
> > lib/librte_ipsec/ses.c | 45 ++++++++++
> > 7 files changed, 306 insertions(+), 3 deletions(-)
> > create mode 100644 lib/librte_ipsec/rte_ipsec.h
> > create mode 100644 lib/librte_ipsec/ses.c
> >
> > diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile
> > index 7758dcc6d..79f187fae 100644
> > --- a/lib/librte_ipsec/Makefile
> > +++ b/lib/librte_ipsec/Makefile
> > @@ -17,8 +17,10 @@ LIBABIVER := 1
> >
> > # all source are stored in SRCS-y
> > SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += sa.c
> > +SRCS-$(CONFIG_RTE_LIBRTE_IPSEC) += ses.c
> >
> > # install header files
> > +SYMLINK-$(CONFIG_RTE_LIBRTE_IPSEC)-include += rte_ipsec.h
> > SYMLINK-$(CONFIG_RTE_LIBRTE_IPSEC)-include += rte_ipsec_sa.h
> >
> > include $(RTE_SDK)/mk/rte.lib.mk
> > diff --git a/lib/librte_ipsec/meson.build b/lib/librte_ipsec/meson.build
> > index 52c78eaeb..6e8c6fabe 100644
> > --- a/lib/librte_ipsec/meson.build
> > +++ b/lib/librte_ipsec/meson.build
> > @@ -3,8 +3,8 @@
> >
> > allow_experimental_apis = true
> >
> > -sources=files('sa.c')
> > +sources=files('sa.c', 'ses.c')
> >
> > -install_headers = files('rte_ipsec_sa.h')
> > +install_headers = files('rte_ipsec.h', 'rte_ipsec_sa.h')
> >
> > deps += ['mbuf', 'net', 'cryptodev', 'security']
> > diff --git a/lib/librte_ipsec/rte_ipsec.h b/lib/librte_ipsec/rte_ipsec.h
> > new file mode 100644
> > index 000000000..5c9a1ed0b
> > --- /dev/null
> > +++ b/lib/librte_ipsec/rte_ipsec.h
> > @@ -0,0 +1,154 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2018 Intel Corporation
> > + */
> > +
> > +#ifndef _RTE_IPSEC_H_
> > +#define _RTE_IPSEC_H_
> > +
> > +/**
> > + * @file rte_ipsec.h
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * RTE IPsec support.
> > + * librte_ipsec provides a framework for data-path IPsec protocol
> > + * processing (ESP/AH).
> > + * IKEv2 protocol support right now is out of scope of that draft.
> > + * Though it tries to define related API in such way, that it could be adopted
> > + * by IKEv2 implementation.
> > + */
> > +
> > +#include <rte_ipsec_sa.h>
> > +#include <rte_mbuf.h>
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +struct rte_ipsec_session;
> > +
> > +/**
> > + * IPsec session specific functions that will be used to:
> > + * - prepare - for input mbufs and given IPsec session prepare crypto ops
> > + * that can be enqueued into the cryptodev associated with given session
> > + * (see *rte_ipsec_crypto_prepare* below for more details).
> > + * - process - finalize processing of packets after crypto-dev finished
> > + * with them or process packets that are subjects to inline IPsec offload
> > + * (see rte_ipsec_process for more details).
> > + */
> > +struct rte_ipsec_sa_func {
> > + uint16_t (*prepare)(const struct rte_ipsec_session *ss,
> > + struct rte_mbuf *mb[],
> > + struct rte_crypto_op *cop[],
> > + uint16_t num);
> > + uint16_t (*process)(const struct rte_ipsec_session *ss,
> > + struct rte_mbuf *mb[],
> > + uint16_t num);
>
> IMO, It makes sense to have separate function pointers for inbound and
> outbound so that, implementation would be clean and we can avoid a
> "if" check.
SA object by itself is unidirectional (either inbound or outbound), so
I don't think we need 2 function pointers here.
Yes, right now, inside ipsec lib we select functions by action_type only,
but it doesn't have to stay that way.
It could be action_type, direction, mode (tunnel/transport), event/poll, etc.
Let say inline_proto_process() could be split into:
inline_proto_outb_process() and inline_proto_inb_process() and
rte_ipsec_sa_func.process will point to appropriate one.
I probably will change things that way for next version.
>
> > +};
> > +
> > +/**
> > + * rte_ipsec_session is an aggregate structure that defines particular
> > + * IPsec Security Association IPsec (SA) on given security/crypto device:
> > + * - pointer to the SA object
> > + * - security session action type
> > + * - pointer to security/crypto session, plus other related data
> > + * - session/device specific functions to prepare/process IPsec packets.
> > + */
> > +struct rte_ipsec_session {
> > +
> > + /**
> > + * SA that session belongs to.
> > + * Note that multiple sessions can belong to the same SA.
> > + */
> > + struct rte_ipsec_sa *sa;
> > + /** session action type */
> > + enum rte_security_session_action_type type;
> > + /** session and related data */
> > + union {
> > + struct {
> > + struct rte_cryptodev_sym_session *ses;
> > + } crypto;
> > + struct {
> > + struct rte_security_session *ses;
> > + struct rte_security_ctx *ctx;
> > + uint32_t ol_flags;
> > + } security;
> > + };
> > + /** functions to prepare/process IPsec packets */
> > + struct rte_ipsec_sa_func func;
> > +};
>
> IMO, it can be cache aligned as it is used in fast path.
Good point, will add.
>
> > +
> > +/**
> > + * Checks that inside given rte_ipsec_session crypto/security fields
> > + * are filled correctly and setups function pointers based on these values.
> > + * @param ss
> > + * Pointer to the *rte_ipsec_session* object
> > + * @return
> > + * - Zero if operation completed successfully.
> > + * - -EINVAL if the parameters are invalid.
> > + */
> > +int __rte_experimental
> > +rte_ipsec_session_prepare(struct rte_ipsec_session *ss);
> > +
> > +/**
> > + * For input mbufs and given IPsec session prepare crypto ops that can be
> > + * enqueued into the cryptodev associated with given session.
> > + * expects that for each input packet:
> > + * - l2_len, l3_len are setup correctly
> > + * Note that erroneous mbufs are not freed by the function,
> > + * but are placed beyond last valid mbuf in the *mb* array.
> > + * It is a user responsibility to handle them further.
> > + * @param ss
> > + * Pointer to the *rte_ipsec_session* object the packets belong to.
> > + * @param mb
> > + * The address of an array of *num* pointers to *rte_mbuf* structures
> > + * which contain the input packets.
> > + * @param cop
> > + * The address of an array of *num* pointers to the output *rte_crypto_op*
> > + * structures.
> > + * @param num
> > + * The maximum number of packets to process.
> > + * @return
> > + * Number of successfully processed packets, with error code set in rte_errno.
> > + */
> > +static inline uint16_t __rte_experimental
> > +rte_ipsec_crypto_prepare(const struct rte_ipsec_session *ss,
> > + struct rte_mbuf *mb[], struct rte_crypto_op *cop[], uint16_t num)
> > +{
> > + return ss->func.prepare(ss, mb, cop, num);
> > +}
> > +
> > +/**
> > + * Finalise processing of packets after crypto-dev finished with them or
> > + * process packets that are subjects to inline IPsec offload.
> > + * Expects that for each input packet:
> > + * - l2_len, l3_len are setup correctly
> > + * Output mbufs will be:
> > + * inbound - decrypted & authenticated, ESP(AH) related headers removed,
> > + * *l2_len* and *l3_len* fields are updated.
> > + * outbound - appropriate mbuf fields (ol_flags, tx_offloads, etc.)
> > + * properly setup, if necessary - IP headers updated, ESP(AH) fields added,
> > + * Note that erroneous mbufs are not freed by the function,
> > + * but are placed beyond last valid mbuf in the *mb* array.
> > + * It is a user responsibility to handle them further.
> > + * @param ss
> > + * Pointer to the *rte_ipsec_session* object the packets belong to.
> > + * @param mb
> > + * The address of an array of *num* pointers to *rte_mbuf* structures
> > + * which contain the input packets.
> > + * @param num
> > + * The maximum number of packets to process.
> > + * @return
> > + * Number of successfully processed packets, with error code set in rte_errno.
> > + */
> > +static inline uint16_t __rte_experimental
> > +rte_ipsec_process(const struct rte_ipsec_session *ss, struct rte_mbuf *mb[],
> > + uint16_t num)
> > +{
> > + return ss->func.process(ss, mb, num);
> > +}
>
> Since we have separate functions and different application path for different mode
> and the arguments also differ. I think, It is better to integrate
> event mode like following
>
> static inline uint16_t __rte_experimental
> rte_ipsec_event_process(const struct rte_ipsec_session *ss, struct rte_event *ev[], uint16_t num)
> {
> return ss->func.event_process(ss, ev, num);
> }
To fulfill that, we can either have 2 separate function pointers:
uint16_t (*pkt_process)( const struct rte_ipsec_session *ss, struct rte_mbuf *mb[],uint16_t num);
uint16_t (*event_process)( const struct rte_ipsec_session *ss, struct rte_event *ev[],uint16_t num);
Or we can keep one function pointer, but change it to accept just array of pointers:
uint16_t (*process)( const struct rte_ipsec_session *ss, void *in[],uint16_t num);
and then make session_prepare() to choose a proper function based on input.
I am ok with both schemes, but second one seems a bit nicer to me.
>
> This is to,
> 1) Avoid Event mode application code duplication
> 2) Better I$ utilization rather moving event specific and mbuff
> specific at different code locations
> 3) Better performance as inside one function pointer we can do things
> in one shot rather splitting the work to application and library.
> 4) Event mode has different modes like ATQ, non ATQ etc, These things
> we can abstract through exiting function pointer scheme.
> 5) atomicity & ordering problems can be sorted out internally with the events,
> having one function pointer for event would be enough.
>
> We will need some event related info (event dev, port, atomic queue to
> use etc) which need to be added in rte_ipsec_session *ss as UNION so it
> wont impact the normal mode. This way, all the required functionality of this library
> can be used with event-based model.
Yes, to support event model, I imagine ipsec_session might need to
contain some event specific data.
I am absolutely ok with that idea in general.
Related fields can be added to the ipsec_session structure as needed,
together with actual event mode implementation.
>
> See below some implementation thoughts on this.
>
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* _RTE_IPSEC_H_ */
> > diff --git a/lib/librte_ipsec/rte_ipsec_version.map b/lib/librte_ipsec/rte_ipsec_version.map
> > +const struct rte_ipsec_sa_func *
> > +ipsec_sa_func_select(const struct rte_ipsec_session *ss)
> > +{
> > + static const struct rte_ipsec_sa_func tfunc[] = {
> > + [RTE_SECURITY_ACTION_TYPE_NONE] = {
> > + .prepare = lksd_none_prepare,
> > + .process = lksd_none_process,
> > + },
> > + [RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO] = {
> > + .prepare = NULL,
> > + .process = inline_crypto_process,
> > + },
> > + [RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL] = {
> > + .prepare = NULL,
> > + .process = inline_proto_process,
> > + },
> > + [RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL] = {
> > + .prepare = lksd_proto_prepare,
> > + .process = lksd_proto_process,
> > + },
>
> [RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL][EVENT] = {
> .prepare = NULL,
> .process = NULL,
> .process_evt = lksd_event_process,
> },
> [RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL][EVENT] = {
> .prepare = NULL,
> .process = NULL,
> .process_evt = inline_event_process,
> },
>
> Probably add one more dimension in array to choose event/poll?
That's a static function/array, surely we can have here as many dimensions as we need to.
As I said below, will probably need to select a function based on direction, mode, etc. anyway.
NP to have extra logic to select event/mbuf based functions.
>
>
> > + };
> > +
> > + if (ss->type >= RTE_DIM(tfunc))
> > + return NULL;
> > +
> > + return tfunc + ss->type;
> > +}
> > diff --git a/lib/librte_ipsec/sa.h b/lib/librte_ipsec/sa.h
> > index ef030334c..13a5a68f3 100644
> > --- a/lib/librte_ipsec/sa.h
> > +++ b/lib/librte_ipsec/sa.h
> > @@ -72,4 +72,7 @@ struct rte_ipsec_sa {
> >
> > } __rte_cache_aligned;
> >
> > +const struct rte_ipsec_sa_func *
> > +ipsec_sa_func_select(const struct rte_ipsec_session *ss);
> > +
> > #endif /* _SA_H_ */
> > diff --git a/lib/librte_ipsec/ses.c b/lib/librte_ipsec/ses.c
> > new file mode 100644
> > index 000000000..afefda937
> > --- /dev/null
> > +++ b/lib/librte_ipsec/ses.c
> > @@ -0,0 +1,45 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2018 Intel Corporation
> > + */
> > +
> > +#include <rte_ipsec.h>
> > +#include "sa.h"
> > +
> > +static int
> > +session_check(struct rte_ipsec_session *ss)
> > +{
> > + if (ss == NULL)
> > + return -EINVAL;
> > +
> > + if (ss->type == RTE_SECURITY_ACTION_TYPE_NONE) {
> > + if (ss->crypto.ses == NULL)
> > + return -EINVAL;
> > + } else if (ss->security.ses == NULL || ss->security.ctx == NULL)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +
> > +int __rte_experimental
> > +rte_ipsec_session_prepare(struct rte_ipsec_session *ss)
> > +{
>
> Probably add one more argument to choose event vs poll so that
> above function pointers can be selected.
>
> or have different API like rte_ipsec_use_mode(EVENT) or API
> other slow path scheme to select the mode.
Yes, we would need something here.
I think we can have some field inside ipsec_session that defines
which input types (mbuf/event) session expects.
I suppose we would need such field anyway - as you said above,
ipsec_session most likely will contain a union for event/non-event related data.
Konstantin
next prev parent reply other threads:[~2018-10-21 22:01 UTC|newest]
Thread overview: 194+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-24 16:53 [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing 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
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 [this message]
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=2601191342CEEE43887BDE71AB9772580102FEA53E@IRSMSX106.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=Anoob.Joseph@cavium.com \
--cc=NarayanaPrasad.Athreya@cavium.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=mohammad.abdul.awal@intel.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).