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 078F82BC9; Tue, 8 Aug 2017 12:01:17 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6870720A47; Tue, 8 Aug 2017 06:01:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 08 Aug 2017 06:01:17 -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=Xojg756hj9PNqXy dZ8hwdPd2SqVdyrKUhMaZErXeLf8=; b=knGXVpk5teH8GYP7KlNtMT/MOA2y1Sg /y5IhdFUKGcCE0GPioRdYexbGZ0VV7mKHA9pbpjio5AeDiC5EIxTQHFumeTI1JIC JaOmLWZcQ8BjZes7r+JhuP3Y8MUv6wXmpOwADE0L3gunvRFzyqUc3RSIXQV1S0oD mrd4C6jYvX+U= 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=Xojg756hj9PNqXydZ8hwdPd2SqVdyrKUhMaZErXeLf8=; b=pd7sL5zn TUUgxq7KZ5ZYZb7ht0kF55wpY5oOiRwpMFvLi8DCzSAsmmwZyjq50L+dj4/HPJE3 BRrgnXa33MKEpWO+2pquQeUU33i0UqAQO2JCVoQzFr6afd72JpeUbpwsdEmRhH5W qnZJjlUFtCDaAjBvv+Wc27g9v/7kQCYqD0D6EVo23USkSUN8FSge9rABDTKt900M C+lXMBLhXZt0tfTqUlN6SddJHXoL5xDWAT2v/LMaRa7sOamxRg6z9fMHbmyylK45 +4K40Rv5yVBUzAIHoeRgBXBCNaWTkEpgPz48oItdF6ig1h8QAbkyRBzftJ15Wbe0 YmzVIuGvtAO6Gg== X-ME-Sender: X-Sasl-enc: Z59BK8MgZHmFTdRST62loqJj/KO3WZRhJN8MZV6ZRZv5 1502186475 Received: from xps.localnet (188.17.136.77.rev.sfr.net [77.136.17.188]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C42F7F9A9; Tue, 8 Aug 2017 06:01:15 -0400 (EDT) From: Thomas Monjalon To: Akhil Goyal Cc: dev@dpdk.org, Shahaf Shuler , Boris Pismenny , Hemant Agrawal , declan.doherty@intel.com, radu.nicolau@intel.com, Aviad Yehezkel , pablo.de.lara.guarch@intel.com, techboard@dpdk.org Date: Tue, 08 Aug 2017 12:00:57 +0200 Message-ID: <2511242.sJGGQ6XytA@xps> In-Reply-To: References: <20170803153211.23073-1-akhil.goyal@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev and ethdev 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, 08 Aug 2017 10:01:19 -0000 08/08/2017 07:03, Shahaf Shuler: > Monday, August 7, 2017 9:07 PM, Boris Pismenny: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > 04/08/2017 07:26, Hemant Agrawal: > > > > On 8/3/2017 9:02 PM, Akhil Goyal wrote: > > > > > Support for security operations is planned to be added in ethdev > > > > > and cryptodev for the 17.11 release. > > > > > > > > > > For this following changes are required. > > > > > - rte_cryptodev and rte_eth_dev structures need to be added new > > > > > parameter rte_security_ops which extend support for security ops > > > > > to the corresponding driver. > > > > > - rte_cryptodev_info and rte_ethd_dev_info need to be added with > > > > > rte_security_capabilities to identify the capabilities of the > > > > > corresponding driver. > > > > > > It is not explained what is the fundamental difference between > > > rte_security and rte_crypto? > > > It looks to be just a technical workaround. > > > > rte_security is a layer between crypto and NIC. > > > > Today crypto sessions are created exclusively against crypto devices, but > > they don't use network related fields, while the network namespace doesn't > > use crypto related fields. We expect this API to represent crypto sessions > > that combine network fields and allow to add/delete them for all devices. > > > > For NICs we will use rte_flow with rte_security for inline/full crypto protocol > > offload such as ESP. > > > > > > > > Why the ABI would be changed by rte_security additions? > > > > > > > > Signed-off-by: Akhil Goyal > > > > > > > > > Acked-by: Hemant Agrawal > > > > > > No more opinions outside of NXP? > > > It seems there is not yet a consensus on how to manage IPsec offloading. > > > I heard there were some phone calls about these stuff but nothing > > > clear appears publicly on the mailing list. > > > Looks to be a community failure. > > > > We agreed to go ahead with this approach on one such phone call. I hope we > > could use the dpdk github for development. > > > > Acked-by: Boris Pismenny > > Acked-by: Shahaf Shuler Applied It means you have a chance to do this change in 17.11. It does not mean you can be sure that the patches will be accepted. This is introducing a new complexity. It must be discussed with the technical board before approving the final design in 17.11.