From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id D40923239 for ; Wed, 16 Sep 2015 10:29:25 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 16 Sep 2015 01:29:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,538,1437462000"; d="scan'208";a="562670261" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.220.110]) ([10.237.220.110]) by FMSMGA003.fm.intel.com with ESMTP; 16 Sep 2015 01:29:24 -0700 To: "dev@dpdk.org" From: "Gonzalez Monroy, Sergio" Message-ID: <55F92863.2040902@intel.com> Date: Wed, 16 Sep 2015 09:29:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dpdk-dev] RFC - IPsec Sample App X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 08:29:26 -0000 We are looking for feedback on the proposal to create a new sample application to showcase the new cryptodev library (1) for acceleration in both SW and HW of crypto processing with a real world example of an IPsec implementation on DPDK. In the proposed implementation the core IPsec logic will be based on a port of NetBSD IPsec kernel module, and will support the ESP protocol and IPv4 tunneling only using statically defined key material (no external IKE client support). * Application Design The sample application will be based on a simple l2fwd application with packets being statically forwarded between defined ports. The IPsec processing of IP packets will occur on the ethdev callbacks. The library will have two processing paths, an ingress(inbound) and egress(outbound) traffic path, which will handle bursts of packets and return bursts of processed packets in an asynchronous fashion. We envisage the APIs for processing bursts looking like the following: int rte_ipsec_ingress_process_burst(struct rte_ipsec_instance *instance, struct rte_mbuf **pkts, int nb_pkts, int max_pkts); int rte_ipsec_egress_process_burst(struct rte_ipsec_instance *instance, struct rte_mbuf **pkts, int nb_pkts, int max_pkts); One or more cryptodevs must be bound to an IPsec instance. If more than one cryptodev is bound to an instance then traffic balancing will be implemented with the caveat that all packets from a flow will always be process on the same cryptodev. It will also be possible to specify that a flow should be processed on a specified device. A set of generic APIs for the configuration of IPsec security policies and associations will be provided, which will be independent of the underlying BSD database implementation. * NOTE This sample app has a dependency on the new DPDK crypto API (1). (1) http://dpdk.org/ml/archives/dev/2015-August/022930.html