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

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

Hi  Jerin,

On 9/6/2017 9:23 PM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Thu, 31 Aug 2017 15:09:45 +0100
>> From: Radu Nicolau <radu.nicolau@intel.com>
>> To: Thomas Monjalon <thomas@monjalon.net>, Akhil Goyal <akhil.goyal@nxp.com>
>> CC: dev@dpdk.org, borisp@mellanox.com, declan.doherty@intel.com,
>>   aviadye@mellanox.com, sandeep.malik@nxp.com, hemant.agrawal@nxp.com,
>>   pablo.de.lara.guarch@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 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 are performed by ethernet device instead of crypto
>>>>>> device. This is also without protocol knowledge inside the ethernet device
>>>>> If the ethernet device can act as a crypto device, this function
>>>>> should be offered via the cryptodev interface.
>>>> yes this could be thought of but the intent was to keep cryptodev and
>>>> ethdev separate, as this would create confusion and will become
>>>> difficult to manage.
>>> I think the reverse: it is confusing to do crypto operations through
>>> ethdev interface.
>>> If a device can do "standalone crypto" and networking, it should appear as
>>> 2 different ports in my opinion.
>>>
>>>>> How is it different from mode RTE_SECURITY_SESS_NONE?
>>>> In RTE_SECURITY_SESS_NONE - crypto device is used for crypto operations.
>>>> In RTE_SECURITY_SESS_ETH_INLINE_CRYPTO - ethernet device is used for
>>>> crypto operations.
>>>> For details of the data path of this mode, refer to the covernote of RFC
>>>> patch from Boris.
>>>> http://dpdk.org/ml/archives/dev/2017-July/070793.html
>>>>
>>>> For implementation of this mode, see patches from Radu,
>>>> http://dpdk.org/ml/archives/dev/2017-August/073587.html
>>> Boris RFC uses rte_flow.
>>> Radu implementation does not use rte_flow.
>>> So I still don't understand the big picture.
>>> Boris asked the question and had no answer.
>> I'll answer here: it was an omission from my side; v2 of the will include
>> rte_flow usage, derived from Boris RFC.
> 
> 
> Cavium would like to contribute to the definition of this specification
> as our HW supports the IPSec offload.
> 
> I was trying to review the latest patch. But it looks like there are
> multiple versions of the header file floating around. like,
> 
> http://dpdk.org/ml/archives/dev/2017-August/073587.html
> http://dpdk.org/ml/archives/dev/2017-August/073738.html
> 
> Can some one tell which one is latest one to review?
> 
> Previously for rte_flow, rte_eventdev specification, etc we had some
> header file sign off before jumping to the RFC implementation. IMO, That
> model was useful where all the vendors could make inline comments on the
> proposal instead of maintaining in the draft repo.  So it possible for
> sending the latest revision of the header file patch on the mailing list
> for the inline comments.
> 

The RFC remained for some time, there were not many comments. so we all 
agreed moved to implementation. That is the point we requested for the 
repo.

The Cavium comments came bit late.

Currently I have just consolidated the patches in the draft repo and I 
am going rebase it and post to mailing list as well in next 1-2 days.

Since, the implementation is started, we will request any subsequent 
comments as an incremental patches.

> Akhil,
> 
> Based on your v2 version, we could map a lot with our HW. However, there
> are three top level quires for the further review.
> 
> 1) Some HW cannot offload all types of packets(like IP fragmented
> packets) and/or there may have back pressure momentarily from IPSec offload
> engine (like Queue is full) etc. So in that case what is the expected behavior
> a) Is it an offload driver responsibility to take care of that or
> b) Is it passed to application as encrypted packets(in case of inbound)
> and the application has to take or of them.
> 

It will depend on the HW capability. If the HW is not supporting the 
fragmented etc packets, they will come as an encrypted packed to the 
application and application need to take care of them.

> 2) In case of inbound traffic, What is the packet format from offload
> driver. i.e
> a) Will ESP header will be removed from the packet area after the
> decryption.
> 
It depend on the session action type. e.g. for inline crypto, the header 
will be intact. for inline proto, the headers will be removed.
In any case, we need to improve the documentation.

> 3) We have a few feature like, anti-replay check, SA expiry((byte/time)
> notification, etc from HW/FW. So it is not clear from the specification
> on the contract between between offload driver vs application
> responsibility? Can you give some insight on that? Especially
> the error notification scheme if it is an offload driver responsibility.
> 

Anti-replay, SA expiry management is still in my todo  list.
The responsibilities will depend on the amount of offloading the HW/FW 
is offering. The current intent is that SA management and expiry is 
being managed by the applicaiton. However, SA expiry event for byte 
based SA will be passed by the HW/FW to application.

In short, the current focus is covering the basic support  only. Rest 
will be incremental.

> This questions will help us to review your proposal and make forward
> progress.
> 
> Thanks,
> /Jerin
> 

Regards,
Akhil