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

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----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.

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.

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.

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.

This questions will help us to review your proposal and make forward
progress.

Thanks,
/Jerin