Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload

[Akhil Goyal <akhil.goyal@nxp.com>]

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);
> 
> What is the usage of this mempool?
this mempool is used to allocate memory for sessions. This API is 
similar to the rte_crypto_session_create API. The same session can be 
used by multiple devices(eth or crypto) and each device can store its 
own private date.
> 
> [...]
>> 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 avoid referencing another proposal without
> - link to the proposal
> - summary of the proposal
The link is not mentioned in the cover note but the patches are sent in 
reply to the same thread that I have mentioned. If we see the complete 
thread, then there should not be any gap.
> 
> [...]
>> 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.
> 
> Again a missing reference (link + summary).
> 
> Even worst, the RFCv2 references this v1 without copying the explanations.
> It is too hard to track, or maybe it is cryptic on purpose ;)
Same comment, patches are sent within the same thread.
Please let me know what is not clear with the thread.

Also, I would take care about this comment, that I need to copy the 
content of previous versions, in my future patches.

As this was an RFC series of patches, the content may not 100% stable, 
and things may get finalized during the course of development across 
Intel/NXP/Mellanox and may be others.

As per my understanding all the information is there in the complete 
thread and nothing looks cryptic to me.

> 
> [...]
>> 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)
> 
> I feel these 4 paths are the most important to discuss.
> Unfortunately there are not enough detailed.
> Please explain the purpose and implementation of each one.
Yes these are 4 paths which can be used for IPSEC.
1. Non protocol offload(RTE_SECURITY_SESS_NONE) - the existing 
application works on this path, the crypto devices perform the crypto 
operations without protocol knowledge.
2. Ipsec inline(RTE_SECURITY_SESS_ETH_INLINE_CRYPTO) - This is when the 
crypto operations are performed by ethernet device instead of crypto 
device. This is also without protocol knowledge inside the ethernet device
3. full protocol offload(RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD) - This is 
same as 2 but with protocol support in the ethernet device.
4. look aside protocol offload(RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD) - 
This is same as 1 but with protocol support in crypto device.

The current application support only the first path. The patchset 
introduces how the other paths can be configured in the 
application/library/driver.

> 
>> 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 */
> 
> In this mode, the ethdev port does the same thing as a crypto port?
not exactly everything. In this mode, only cipher and auth operations 
are performed by the eth device. No intelligence about the protocol is 
done. This is similar to what the current implementation do with the 
crypto device(Non protocol offload).
> 
>>          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.
>>           */
> 
> I guess the difference between ETH_PROTO_OFFLOAD and CRYPTO_PROTO_OFFLOAD
> is that we must re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC?
yes
> 
>>          RTE_SECURITY_SESS_NONE
>> 	/**< Non protocol offload. Application need to manage everything */
>> };
> 
> What RTE_SECURITY_SESS_NONE does? It is said to be implemented above.
It is non protocol offload mentioned above.
> 
> 

Thanks for reviewing the patch set. Please let me know if you have any 
more queries.

Regards,
Akhil