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.nico...@intel.com>
To: Thomas Monjalon <tho...@monjalon.net>, Akhil Goyal <akhil.go...@nxp.com>
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
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
