From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 890941B505 for ; Tue, 9 Oct 2018 20:24:49 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 11:24:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,361,1534834800"; d="scan'208";a="264255197" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga005.jf.intel.com with ESMTP; 09 Oct 2018 11:24:39 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 9 Oct 2018 19:24:38 +0100 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.45]) by irsmsx111.ger.corp.intel.com ([169.254.2.200]) with mapi id 14.03.0319.002; Tue, 9 Oct 2018 19:24:38 +0100 From: "Ananyev, Konstantin" To: Jerin Jacob CC: "Joseph, Anoob" , "dev@dpdk.org" , "Awal, Mohammad Abdul" , "Doherty, Declan" , Narayana Prasad , "akhil.goyal@nxp.com" , "hemant.agrawal@nxp.com" , "shreyansh.jain@nxp.com" Thread-Topic: [dpdk-dev] [RFC] ipsec: new library for IPsec data-path processing Thread-Index: AQHUO8sQ1vNhPIIy2kCq+ieD7nPPdqTefpOAgABfO7CAAuY7AIALGZsggAAAuDCABMYgAIABKxCAgAHAZSCAAdkHgIAHoQHQgATz/oCACdi0gIAAmlaAgAoN9CA= Date: Tue, 9 Oct 2018 18:24:37 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580102FE44B8@IRSMSX106.ger.corp.intel.com> References: <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> <20180918175433.GA16116@jerin> <2601191342CEEE43887BDE71AB977258EA95A68A@irsmsx105.ger.corp.intel.com> <20180926180256.GA3069@jerin> <2601191342CEEE43887BDE71AB9772580102FE113C@IRSMSX106.ger.corp.intel.com> <20181003093718.GA14844@jerin> In-Reply-To: <20181003093718.GA14844@jerin> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTAzNTAxYjQtN2U5ZC00OWUxLWE2ZGItOWM2Y2RlYmVmOTJkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiS255dXYrZWJNZk5VU2wzRmhzNlhhRyszWEJERHJjMzA3UTJaTXpTM1k0R1NCeU1HZW1yTzdSQWFDaGFBaGFUZiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.182] 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, 09 Oct 2018 18:24:50 -0000 Hi Jerin, > > > > > static inline rte_ipsec_add_tunnel_hdr(struct rte_mbuf *mbuf); > > > static inline rte_ipsec_update_sqn(struct rte_mbuf *mbuf, &seq_no); > > > ... > > > > > > For the regular use case, a fat > > > rte_ipsec_(inbound/outbound)_(prepare/process) can be provided. The > > > worker implemented for that case can directly call the function and > > > forget about the other modes. For other vendors with varying > > > capabilities, there can be multiple workers taking advantage of the h= w > > > features. For such workers, the static inline functions can be used a= s > > > required. This gives vendors opportunity to pick and choose what they > > > want from the ipsec lib. The worker to be used for that case will be > > > determined based on the capabilities exposed by the PMDs. > > > > > > https://mails.dpdk.org/archives/dev/2018-June/103828.html > > > > > > The above email explains how multiple workers can be used with l2fwd. > > > > > > For this to work, the application & library code need to be modularis= ed. > > > Like what is being done in the following series, > > > https://mails.dpdk.org/archives/dev/2018-June/103786.html > > > > > > This way one application can be made to run on multiple platforms, wi= th > > > the app being optimized for the platform on which it would run. > > > > > > /* ST SA - RTE_SECURITY_ACTION_TYPE_NONE - CRYPTODEV - NO EVENTDEV*/ > > > worker1() > > > { > > > while(true) { > > > nb_pkts =3D rte_eth_rx_burst(); > > > > > > if (nb_pkts !=3D 0) { > > > /* Do lookup */ > > > rte_ipsec_inbound_prepare(); > > > rte_cryptodev_enqueue_burst(); > > > /* Update in-flight */ > > > } > > > > > > if (in_flight) { > > > rte_cryptodev_dequeue_burst(); > > > rte_ipsec_outbound_process(); > > > } > > > /* route packet */ > > > } > > > > > > #include /* For IPsec lib static inlines */ > > > > > > static inline rte_event_enqueue(struct rte_event *ev) > > > { > > > ... > > > } > > > > > > /* MT safe SA - RTE_SECURITY_ACTION_TYPE_NONE - CRYPTODEV - EVENTDEV) > > > worker2() > > > { > > > while(true) { > > > nb_pkts =3D rte_eth_rx_burst(); > > > > > > if (nb_pkts !=3D 0) { > > > /* Do lookup */ > > > rte_ipsec_add tunnel(ev->mbuf); > > > rte_event_enqueue(ev) > > > rte_cryptodev_enqueue_burst(ev->mbuf); > > > /* Update in-flight */ > > > } > > > > > > if (in_flight) { > > > rte_cryptodev_dequeue_burst(); > > > rte_ipsec_outbound_process(); > > > } > > > /* route packet */ > > > } > > > > Hmm, not sure how these 2 cases really differs in terms of ipsec proces= sing. > > I do understand the in second one we use events to propagate packets th= rough the system, > > and that eventdev might be smart enough to preserve packet ordering, et= c. > > But in terms of ipsec processing we have to do exactly the same for bot= h cases. > > Let say for the example above (outbound, crytpodev): > > a) lookup an SA > > b) increment SA.SQN and check for overflow > > d) generate IV > > e) generate & fill ESP header/trailer, tunnel header > > f) perform actual encrypt, generate digest > > > > So crypto_prepare() - deals with b)-e). > > f) is handled by cryptodev. > > Yes, step b) might need to be atomic, or might not - > > depends on particular application design. > > But in both cases (polling/eventdev) we do need all these steps to be p= erformed. >=20 > The real question, Is the new library should be aware of eventdev or > application decides it? My thought right now - it shouldn't. Looking at rte_event_crypto_adapter - right now it accepts crypto-ops as in= put for both new and forward modes. Which means that prepare() has to called by the app before doing enqueue (either straight to cryptodev or to eventdev). Anyway I just sumitted RFC v2 with process/prepare as function pointers inside ipsec_session, please have a look. Konstantin >=20 > If it is former, in order to complete step (b), we need rte_event also pa= ssed to > _process() API and process() API needs to be function pointer in order to > accommodate all combinations of different HW/SW capabilities. >=20 >=20