> > > To: Thomas Monjalon , Akhil Goyal
> > >
> > > CC: dev@dpdk.org, bor...@mellanox.com, declan.dohe...@intel.com,
> > > avia...@mellanox.com, sandeep.ma...@nxp.com, hemant.agra...@nxp.com,
> > > pablo.de.lara.gua...@intel.com
> > > Sub
...@nxp.com,
pablo.de.lara.gua...@intel.com
Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto
offload
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.1.0
On 8/31/2017 2:14 PM, Thomas Monjalon wrote:
31/08/2017 12:52, Akhil
a.gua...@intel.com
> Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto
> offload
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.1.0
>
>
> On 8/31/2017 2:14 PM, Thomas Monjalon wrote:
> > 31/08/2017 1
On 8/31/2017 2:14 PM, Thomas Monjalon wrote:
31/08/2017 12:52, Akhil Goyal:
On 8/31/2017 3:36 PM, Thomas Monjalon wrote:
31/08/2017 11:37, Akhil Goyal:
On 8/29/2017 8:19 PM, Thomas Monjalon wrote:
25/07/2017 13:21, Akhil Goyal:
2. Ipsec inline(RTE_SECURITY_SESS_ETH_INLINE_CRYPTO) - This is
31/08/2017 12:52, Akhil Goyal:
> On 8/31/2017 3:36 PM, Thomas Monjalon wrote:
> > 31/08/2017 11:37, Akhil Goyal:
> >> On 8/29/2017 8:19 PM, Thomas Monjalon wrote:
> >>> 25/07/2017 13:21, Akhil Goyal:
> >> 2. Ipsec inline(RTE_SECURITY_SESS_ETH_INLINE_CRYPTO) - This is when the
> >> crypto operations
On 8/31/2017 3:36 PM, Thomas Monjalon wrote:
31/08/2017 11:37, Akhil Goyal:
On 8/29/2017 8:19 PM, Thomas Monjalon wrote:
25/07/2017 13:21, Akhil Goyal:
These are very similar to what Declan proposed with a few additions.
This can be updated further for other security protocols like MACSec and
31/08/2017 11:37, Akhil Goyal:
> On 8/29/2017 8:19 PM, Thomas Monjalon wrote:
> > 25/07/2017 13:21, Akhil Goyal:
> >> 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
> >
> > You should avo
Hi Thomas,
On 8/29/2017 8:19 PM, Thomas Monjalon wrote:
Hi,
I try to understand how things are connected,
but too many things are not clear for someone not involved in security.
25/07/2017 13:21, Akhil Goyal:
struct rte_security_session *
rte_security_session_create(struct rte_mempool *mempool
Hi,
I try to understand how things are connected,
but too many things are not clear for someone not involved in security.
25/07/2017 13:21, Akhil Goyal:
> struct rte_security_session *
> rte_security_session_create(struct rte_mempool *mempool);
What is the usage of this mempool?
[...]
> These a
On 8/2/2017 6:46 PM, Hemant Agrawal wrote:
Hi Declan,
On 7/26/2017 7:16 PM, Declan Doherty wrote:
Hey Akhil, I like the proposal of allowing the rte_secruity API to be
supported on both NIC and crypto devices as I think it allows us to
cover all the protocol offload scenarios in a consist manne
Hi Declan,
On 7/26/2017 7:16 PM, Declan Doherty wrote:
Hey Akhil, I like the proposal of allowing the rte_secruity API to be
supported on both NIC and crypto devices as I think it allows us to
cover all the protocol offload scenarios in a consist manner.
The main concern I have is in regards to
Hey Akhil, I like the proposal of allowing the rte_secruity API to be
supported on both NIC and crypto devices as I think it allows us to
cover all the protocol offload scenarios in a consist manner.
The main concern I have is in regards to the device identification in a
consistent manner betw
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
13 matches
Mail list logo