From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 696D4137C for ; Tue, 18 Sep 2018 14:43:31 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2018 05:43:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,389,1531810800"; d="scan'208";a="233893718" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga004.jf.intel.com with ESMTP; 18 Sep 2018 05:42:10 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.54]) by IRSMSX106.ger.corp.intel.com ([169.254.8.41]) with mapi id 14.03.0319.002; Tue, 18 Sep 2018 13:42:09 +0100 From: "Ananyev, Konstantin" To: "Ananyev, Konstantin" , Jerin Jacob , "Joseph, Anoob" CC: "dev@dpdk.org" , "Awal, Mohammad Abdul" , "Doherty, Declan" , Narayana Prasad , Hemant Agrawal , "shreyansh.jain@nxp.com" Thread-Topic: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing Thread-Index: AQHUO8sQ1vNhPIIy2kCq+ieD7nPPdqTefpOAgABfO7CAAuY7AIALGZsggAAAuDCABMYgAIABKxCAgAHAZSCAAYwIoA== Date: Tue, 18 Sep 2018 12:42:08 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258EA957E3A@irsmsx105.ger.corp.intel.com> References: <1535129598-27301-1-git-send-email-konstantin.ananyev@intel.com> <358d1b6c-26f2-b125-07a4-cfb1c0e2a57b@caviumnetworks.com> <2601191342CEEE43887BDE71AB977258EA95089D@irsmsx105.ger.corp.intel.com> <475cf471-b46a-671a-5485-0042c652430c@caviumnetworks.com> <2601191342CEEE43887BDE71AB977258EA954BAD@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258EA954E9D@irsmsx105.ger.corp.intel.com> <20180916105640.GA4803@jerin> <2601191342CEEE43887BDE71AB977258EA95724C@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258EA95724C@irsmsx105.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzIzNjI1NmMtODllNS00MWFkLWFiMjgtZWI5NjVhYzIxYmYxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiN0RxY01HSjVvVE03NEpJZW5mVE9kaEpIczNOTzh4M2NuOGs2Y0RYK0Nyb3J6cll0dHk4bmlmd0g0b3ZsZEZsQiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing 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: Tue, 18 Sep 2018 12:43:32 -0000 > > I am not saying this should be the ONLY way to do as it does not work > > very well with non NPU/FPGA class of SoC. > > > > So how about making the proposed IPSec library as plugin/driver to > > rte_security. >=20 > As I mentioned above, I don't think that pushing whole IPSec data-path in= to rte_security > is the best possible approach. > Though I probably understand your concern: > In RFC code we always do whole prepare/process in SW (attach/remove ESP h= eaders/trailers, so paddings etc.), > i.e. right now only device types: RTE_SECURITY_ACTION_TYPE_NONE and RTE_S= ECURITY_ACTION_TYPE_INLINE_CRYPTO are covered. > Though there are devices where most of prepare/process can be done in HW > (RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL/RTE_SECURITY_ACTION_TYPE_LOOKAS= IDE_PROTOCOL), > plus in future could be devices where prepare/process would be split betw= een HW/SW in a custom way. > Is that so? > To address that issue I suppose we can do: > 1. Add support for RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECUR= ITY_ACTION_TYPE_LOOKASIDE_PROTOCOL > security devices into ipsec. > We planned to do it anyway, just don't have it done yet. > 2. For custom case - introduce RTE_SECURITY_ACTION_TYPE_INLINE_CUSTOM and= RTE_SECURITY_ACTION_TYPE_LOOKASIDE_CUSTOM > and add into rte_security_ops new functions: > uint16_t lookaside_prepare(struct rte_security_session *sess, struct = rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num); > uint16_t lookaside_process(struct rte_security_session *sess, struct = rte_mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num); > uint16_t inline_process(struct rte_security_session *sess, struct rte= _mbuf *mb[], struct struct rte_crypto_op *cop[], uint16_t num); > So for custom HW, PMD can overwrite normal prepare/process behavior. >=20 Actually after another thought:=20 My previous assumption (probably wrong one) was that for both RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL and RTE_SECURITY_ACTION_TYPE_LOOKA= SIDE_PROTOCOL devices can do whole data-path ipsec processing totally in HW - no need for= any SW support (except init/config). Now looking at dpaa and dpaa2 devices (the only ones that supports RTE_SECU= RITY_ACTION_TYPE_LOOKASIDE_PROTOCOL right now) I am not so sure about that - looks like some SW help might be needed for r= eplay window updates, etc. =20 Hemant, Shreyansh - can you guys confirm what is expected from RTE_SECURITY= _ACTION_TYPE_LOOKASIDE_PROTOCOL devices (HW/SW roses/responsibilities)? About RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL - I didn't find any driver = inside DPDK source tree that does support that capability. So my question is there any devices/drivers that do support it? If so, where could source code could be found, and what are HW/SW roles/res= ponsibilities for that type of devices? Konstantin