DPDK patches and discussions
 help / color / mirror / Atom feed
From: Akhil Goyal <akhil.goyal@nxp.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	"Joseph, Anoob" <Anoob.Joseph@caviumnetworks.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Awal, Mohammad Abdul" <mohammad.abdul.awal@intel.com>,
	"Doherty, Declan" <declan.doherty@intel.com>,
	Narayana Prasad <narayanaprasad.athreya@caviumnetworks.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	"shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>
Subject: Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing
Date: Tue, 25 Sep 2018 13:18:09 +0530	[thread overview]
Message-ID: <36e1d53b-4c31-1a92-c91f-7066f4358f79@nxp.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258EA95A705@irsmsx105.ger.corp.intel.com>

Hi Konstantin,

On 9/24/2018 4:21 PM, Ananyev, Konstantin wrote:
> Hi Akhil,
>
>> Hi Konstantin,
>>
>> On 9/18/2018 6:12 PM, Ananyev, Konstantin wrote:
>>>>> I am not saying this should be the ONLY way to do as it does not work
>>>>> very well with non NPU/FPGA class of SoC.
>>>>>
>>>>> So how about making the proposed IPSec library as plugin/driver to
>>>>> rte_security.
>>>> As I mentioned above, I don't think that pushing whole IPSec data-path into rte_security
>>>> is the best possible approach.
>>>> Though I probably understand your concern:
>>>> In RFC code we always do whole prepare/process in SW (attach/remove ESP headers/trailers, so paddings etc.),
>>>> i.e. right now only device types: RTE_SECURITY_ACTION_TYPE_NONE and RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO are covered.
>>>> Though there are devices where most of prepare/process can be done in HW
>>>> (RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL/RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL),
>>>> plus in future could be devices where prepare/process would be split between HW/SW in a custom way.
>>>> Is that so?
>>>> To address that issue I suppose we can do:
>>>> 1. Add support for RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
>>>>       security devices into ipsec.
>>>>       We planned to do it anyway, just don't have it done yet.
>>>> 2. For custom case - introduce RTE_SECURITY_ACTION_TYPE_INLINE_CUSTOM and
>> RTE_SECURITY_ACTION_TYPE_LOOKASIDE_CUSTOM
>>>>       and add into rte_security_ops   new functions:
>>>>       uint16_t lookaside_prepare(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t
>> num);
>>>>       uint16_t lookaside_process(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t
>> num);
>>>>       uint16_t inline_process(struct rte_security_session *sess, struct rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num);
>>>>       So for custom HW, PMD can overwrite normal prepare/process behavior.
>>>>
>>> Actually  after another thought:
>>> My previous assumption (probably wrong one) was that for both
>>> RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
>>> devices can do whole data-path ipsec processing totally in HW - no need for any SW support (except init/config).
>>> Now looking at dpaa and dpaa2 devices (the only ones that supports RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL right now)
>>> I am not so sure about that - looks like some SW help might be needed for replay window updates, etc.
>>> Hemant, Shreyansh - can you guys confirm what is expected from RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL devices
>>> (HW/SW roses/responsibilities)?
>>> About RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL  - I didn't find any driver inside DPDK source tree that does support that
>> capability.
>>> So my question is there any devices/drivers that do support it?
>>> If so, where could source code could be found, and what are HW/SW roles/responsibilities for that type of devices?
>>> Konstantin
>>>
>>>
>> In case of LOOKASIDE, the protocol errors like antireplay and sequence
>> number overflow shall be the responsibility of either PMD or the HW.
>> It should notify the application that the error has occurred and
>> application need to decide what it needs to decide next.
> Ok, thanks for clarification.
> Just to confirm -  do we have a defined way for it right now in rte_security?
As of now, there are no macros defined for antireplay/seq. no. overflow 
errors in crypto errors(rte_crypto_op_status), but it will be added soon.
For inline cases, ipsec-secgw application gets error notification via 
rte_eth_event.
>
>> As Jerin said in other email, the roles/responsibility of the PMD in
>> case of inline proto and lookaside case, nothing much is required from
>> the application to do any processing for ipsec.
>>
>> As per my understanding, the proposed RFC is to make the application
>> code cleaner for  the protocol processing.
> Yes, unified data-path API is definitely one of the main goals.
>
>> 1. For inline proto and lookaside there won't be any change in the data
>> path. The main changes would be in the control path.
> Yes, from your and Jerin description data-path processing looks
> really lightweight for these cases.
> For control path - there is no much change, user would have to call
> rte_ipsec_sa_init() to start using given SA.
>
>> 2. But in case of inline crypto and RTE_SECURITY_ACTION_TYPE_NONE, the
>> protocol processing will be done in the library and there would be
>> changes in both control and data path.
> Yes.
>
>> As the rte_security currently provide generic APIs for control path only
>> and we may have it expanded for protocol specific datapath processing.
>> So for the application, working with inline crypto/ inline proto would
>> be quite similar and it won't need to do some extra processing for
>> inline crypto.
>> Same will be the case for RTE_SECURITY_ACTION_TYPE_NONE and lookaside.
>>
>> We may have the protocol specific APIs reside inside the rte_security
>> and we can use either the crypto/net PMD underneath it.
> As I understand, you suggest instead of introducing new library,
> introduce similar data-path functions inside rte_security.
> Probably something like:
>
> uint16_t rte_security_process(struct rte_security_session *s, struct rte_mbuf *mb[], uint16_t num);
> uint16_t rte_security_crypto_prepare(struct rte_ipsec_sa *sa, struct rte_mbuf *mb[],
>                                                                        struct rte_crypto_op *cop[], uint16_t num);
> ...
> Is that correct?

"rte_security_process_ipsec" and "rte_security_crypto_prepare_ipsec" will be better.
We can have such APIs for other protocols as well.
Also, we should leave the existing functionality as is and we should let the user decide whether
it needs to manage the ipsec on it's own or with the new APIs.

>
> I thought about that approach too, and indeed from one side it looks cleaner and easier
> to customize - each of these functions would just call related function inside rte_security_ops.
> The problem with that approach - it would mean that each SA would be able to work with one
> device only.
> So if someone needs an SA that could be processed by multiple cores and multiple crypto-devices
> in parallel such approach wouldn’t fit.
One SA should be processed by a single core or else we need to have an 
event based application which support ordered queues,
because if we process packets of single SA on multiple cores, then 
packets will get re-ordered and we will get the anti-replay late errors 
on decap side.
And if we have event based solution, then the scheduler will be able to 
handle the load balancing accordingly.

> That was the main reason to keep rte_security as it is right now and go ahead with new library.
> One thing that worries me -  do we need a way to share SQN and replay window information
> between rte_security and upper layer (rte_ipsec)?
> If 'no', then ok, if 'yes' then probably we need to discuss how to do it now?
anti-replay window size shall be a parameter in ipsec_xform, which shall 
be added.
And the error notification
  - in case of using crypto, then use rte_crypto_op_status
- in case of inline cases, then use rte_eth_event callbacks.
I don't see rte_ipsec needs to take care of that in your initial approach.
However, if you plan to include session reset inside rte_ipsec, then you 
may need that inside the rte_ipsec.
And yes that would be tricky.

-Akhil

  reply	other threads:[~2018-09-25  7:48 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
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 [this message]
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=36e1d53b-4c31-1a92-c91f-7066f4358f79@nxp.com \
    --to=akhil.goyal@nxp.com \
    --cc=Anoob.Joseph@caviumnetworks.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mohammad.abdul.awal@intel.com \
    --cc=narayanaprasad.athreya@caviumnetworks.com \
    --cc=shreyansh.jain@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).