From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C873CA057B; Tue, 14 Apr 2020 15:24:20 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A02C51C244; Tue, 14 Apr 2020 15:24:20 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 21FD01C222 for ; Tue, 14 Apr 2020 15:24:19 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 81FD6580973; Tue, 14 Apr 2020 09:24:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 14 Apr 2020 09:24:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=SomFUlT9Hy1peGfd4cMf48kmWeyjD+17NoE9Qc0SUxo=; b=Kpxbbj04Ud/W x/VkJX2UmuT/4F5B9qfrmSDqHnqGpHyDSfpuvGlgi2x2Ha3XD8csORZP8Llmh5jD TxNQ2sqKX5EI8U2ULPn+RIUD8Uz0DTW13KUAulHXPmjyv7Xx8ufQUGIBKi/CUUBn gbqztnexVwmyBkj06gUbCuEc88+lfiY= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=SomFUlT9Hy1peGfd4cMf48kmWeyjD+17NoE9Qc0SU xo=; b=mXCe5cdwFJwSURqiZOF5HJCoB8PZfXdqrRk3WCaLApomDWlLnxW9dZmBa kBg5bJl9EvnfdjfKfaKjrpE+5JFJBb12NiB0QL3KpH/HXu2bcPqFzxSw08GjJEPl 5zcrx41WELu5vST6g52/1jsfOUkuo8JouZpLFEaetPKUa/1bArBFpj/eFZiOYTyl pzvX3nrPDRdeATNeKNCDkHmkkncgKmzgdEROMRQ+ba0o/y0SpndZAauJF04XBmqG Mvu7lHauvNNdsEU4Bbc/uKHYfHd1DKRop9eDbYwMIFCI7WGb2ioEJLO/++R+rI2a 7nexPKVZxwRUd+ypmuQHn67csMqBQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfedugdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepughpughkrdhorhhgpdhouhhtlhhoohhkrdgtohhmnecukfhppeejjedrudef gedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B71573280064; Tue, 14 Apr 2020 09:24:15 -0400 (EDT) From: Thomas Monjalon To: "Yigit, Ferruh" , "Trahe, Fiona" Cc: "Coyle, David" , "dev@dpdk.org" , "Doherty, Declan" , "De Lara Guarch, Pablo" , "Ryan, Brendan" , "shreyansh.jain@nxp.com" , "hemant.agrawal@nxp.com" , "akhil.goyal@nxp.com" , Anoob Joseph , Ruifeng Wang , Liron Himi , Nagadheeraj Rottela , Srikanth Jampala , Gagandeep Singh , Jay Zhou , Ravi Kumar , "Richardson, Bruce" , "Trahe, Fiona" Date: Tue, 14 Apr 2020 15:24:14 +0200 Message-ID: <5745012.CvnuH1ECHv@thomas> In-Reply-To: References: <20200410142757.31508-1-david.coyle@intel.com> <3280198.8hb0ThOEGa@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 14/04/2020 15:04, Trahe, Fiona: > > 14/04/2020 12:21, Ferruh Yigit: > > http://inbox.dpdk.org/dev/MN2PR11MB35507D4B96677A41E66440C5E3C30@MN2PR11MB3550.na > > mprd11.prod.outlook.com/ > > > > I am not convinced. > > I don't like rawdev in general. > > Rawdev is good only for hardware support which cannot be generic > > like SoC, FPGA management or DMA engine. > > [Fiona] CRC and BIP are not crypto algorithms, they are error detection processes. > So there is no class in DPDK that these readily fit into. > There was resistance to adding another xxxddev, and even if one had been added > for error_detection_dev, there would still have been another layer needed > to couple this with cryptodev. Various proposals for this have been discussed on the ML > in RFC and recent patches, there doesn't seem to be an appetite for this as a generic API. > So it seems that only Intel has software and hardware engines that provide this > specialised feature coupling. In that case rawdev seems like the most > appropriate vehicle to expose this. Adding some vendor-specific API is not a good answer. It will work in some cases, but it won't make DPDK better. What's the purpose of DPDK if it's not solving a common problem for different hardware? > > Here the intent is to use rawdev because we don't find a good API. > > API defeat is a no-go. > > [Fiona] It's not that we haven't found a good API, but that there doesn't seem > to be a general requirement for such a specialised API There is a requirement to combine features of different classes. In the past, rte_security was an "answer" to this issue with crypto and ethdev. This is a real topic, please let's find a generic elegant solution.