From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id E795FFE5 for ; Thu, 31 Aug 2017 15:14:39 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8A61220EDD; Thu, 31 Aug 2017 09:14:39 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 31 Aug 2017 09:14:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=BNXIYwv8Z/IDIjl WNmolW4Ka5nymbwWNrWIQLHp+3g4=; b=ZUE+DNw3t2arRLWJTi9G2chN9c5nQhj X4Kjb0JUwbGzks6oym0ba7cEo4DkspVQ19jazrq402+3QPPBPb5e5Wt7V9C3emuH 0wfWSekYgB16DBlj5jLKfJTjPRRVcMtE4L88Z3yzOnDTEmfgx5R0FHK4JRAn7Buo 1uSpA0GmqulY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=BNXIYwv8Z/IDIjlWNmolW4Ka5nymbwWNrWIQLHp+3g4=; b=AX+zDMGb bSm2rYcoZIRL3C4KiGEztFL8iJ+Agk6cEpnl1Rhy9leELTySgkNlt3EB/Egsf5Lm OA3rXprOcbgAdqpTdSxnk6g3LWQUr2k3QCImmZqhE/Yb6z8IEbjbT7Vn5EO2jAfm shMsIkxUomE3xb9a4XG3xs+uRHJP9nAdYyr32EcBLJMM/zqy66HM0j3n+4HmaxbM kg/IMCHA0GN7eFLmDqOLI0DzpQL27X9UyPT4C5ZLxu7IRl4hA2/8rKzwp3i5IcUq RtRyoNZZ9hu9yNz0OZ43uXopyIK7m0U2r67wD+paCHjEvWO4ZafafBOurfSLAQ2N epbqrlk5brTiNQ== X-ME-Sender: X-Sasl-enc: N2uHA87YUbw1k4hrtLuiXPF7Teqclqk3se822vO744el 1504185279 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 30D0D7E8F0; Thu, 31 Aug 2017 09:14:39 -0400 (EDT) From: Thomas Monjalon To: Akhil Goyal Cc: dev@dpdk.org, borisp@mellanox.com, declan.doherty@intel.com, radu.nicolau@intel.com, aviadye@mellanox.com, sandeep.malik@nxp.com, hemant.agrawal@nxp.com, pablo.de.lara.guarch@intel.com Date: Thu, 31 Aug 2017 15:14:38 +0200 Message-ID: <5392171.j1FdNZENvz@xps> In-Reply-To: <874c2bd0-d097-5082-8a9d-1f9341505ac6@nxp.com> References: <7834b3bd-0800-500c-1c89-3b89e2eb47fa@nxp.com> <7410549.rg854U5vhU@xps> <874c2bd0-d097-5082-8a9d-1f9341505ac6@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 13:14:40 -0000 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. > > 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.