From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 09F1FFE5 for ; Thu, 31 Aug 2017 16:09:51 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP; 31 Aug 2017 07:09:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,453,1498546800"; d="scan'208";a="306561700" Received: from rnicolau-mobl.ger.corp.intel.com (HELO [10.237.221.79]) ([10.237.221.79]) by fmsmga004.fm.intel.com with ESMTP; 31 Aug 2017 07:09:46 -0700 To: Thomas Monjalon , Akhil Goyal 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 References: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com> <7410549.rg854U5vhU@xps> <874c2bd0-d097-5082-8a9d-1f9341505ac6@nxp.com> <5392171.j1FdNZENvz@xps> From: Radu Nicolau Message-ID: <94a4b6b5-a80a-9884-244a-02131c695eff@intel.com> Date: Thu, 31 Aug 2017 15:09:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <5392171.j1FdNZENvz@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 14:09:52 -0000 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. > >>> Is there direct Rx/Tx involved in this mode? >> No the packet will come to the application and will add/remove relevant >> headers and then send the packet to the appropriate eth dev after route >> lookup. >> >>>> 3. full protocol offload(RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD) - This is >>>> same as 2 but with protocol support in the ethernet device. >>> Is there direct Rx/Tx in RTE_SECURITY_SESS_ETH_PROTO_OFFLOAD? >> No, there should not be direct rx/tx as the application will do route >> lookup and send the packet to relevant ethernet interface. >>>> 4. look aside protocol offload(RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD) - >>>> This is same as 1 but with protocol support in crypto device. >>> Who is responsible for Rx/Tx in RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD? >> The packet is returned back to the application as in the case of non >> protocol offload. But the application doesnt need to take care of the >> headers and other protocol specifics. It just need to forward the packet >> to the relevent eth dev after route lookup. >> Please refer to RFC v2 of the proposal it has more details in the header >> file rte_security.h and the implementation using the ipsec-secgw >> application. >> http://dpdk.org/ml/archives/dev/2017-August/072900.html > So there is no direct Rx/Tx in any mode? > What is the point of using an ethdev port if there is no Rx/Tx? > >>> [...] >>>>>> 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). >>> Are you saying no but yes? >>> I say "ethdev port does the same thing as a crypto port" >>> You say "similar to what the current implementation do with the crypto device" >> This is said so because the crypto device may also support 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 >>> OK >>> Who is responsible to re-inject packets from CRYPTO_PROTO_OFFLOAD to the NIC? >> Application will do the forwarding after route lookup >>>>>> 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. >>> How is it different from using cryptodev? >> No it is not different. It is just to mention that there is no security >> session involved and the application will use the cryptodev. > As far as I understand, my vote is a NACK for the current proposal.