-----Original Message----- > Date: Fri, 8 Sep 2017 16:42:56 +0530 > From: Akhil Goyal <akhil.go...@nxp.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com>, Radu Nicolau > <radu.nico...@intel.com> > CC: Thomas Monjalon <tho...@monjalon.net>, 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, pathr...@caviumnetworks.com, > andriy.berestovs...@cavium.com, sunil.kulka...@cavium.com, > balasubramanian.manoha...@cavium.com, suheil.chand...@cavium.com > Subject: Re: [RFC PATCH 0/1] IPSec Inline and look aside crypto offload > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.3.0 > > Hi Jerin,
Hi Akhil, > > 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. Yes. Nothing much happened on mailing list, All we saw a few comments from Thomas and which ended up as NACK. > > 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. OK. We will review it. > > 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. OK > > > 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. I thought, we need to keep the header in both cases otherwise the application may not able to check anti-replay if ESP header removed. > > > 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. Makes sense. This is the hard part to solve in inline HW IPSec implementation. I suggest to keep API experimental till we solve this hard problems which are tightly coupled with HW capabilities.
