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 CCF97A0588; Thu, 16 Apr 2020 00:20:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A488C1DA43; Thu, 16 Apr 2020 00:20:02 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id B07201DA42 for ; Thu, 16 Apr 2020 00:20:00 +0200 (CEST) IronPort-SDR: OFkrYQCKeJ1rW/L4alZ+bkF0si+bcA5LCxflImSD/l2HOKrZfPIactvAt5NBDYlThpstDkQrzb wP5Q+Xquk6jw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2020 15:19:59 -0700 IronPort-SDR: WpqB6ES30H22xzLHCt1zqxtqoZ2cxAoDWpQbWB6gTdv9Z8FmEmKJV++EXLZDtRsLJKBbu0cK6C L3PPENJTjRDA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,388,1580803200"; d="scan'208";a="454090015" Received: from dwdohert-mobl.ger.corp.intel.com (HELO [10.252.12.166]) ([10.252.12.166]) by fmsmga005.fm.intel.com with ESMTP; 15 Apr 2020 15:19:55 -0700 To: Thomas Monjalon , "Yigit, Ferruh" , "Trahe, Fiona" Cc: "Coyle, David" , "dev@dpdk.org" , "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" References: <20200410142757.31508-1-david.coyle@intel.com> <5745012.CvnuH1ECHv@thomas> <4421330.vfdyTQepKt@thomas> From: "Doherty, Declan" Message-ID: <2fa52616-2e81-4eae-a28b-4549154742fe@intel.com> Date: Wed, 15 Apr 2020 23:19:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <4421330.vfdyTQepKt@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 14/04/2020 3:44 PM, Thomas Monjalon wrote: > 14/04/2020 16:02, Trahe, Fiona: >> Hi Thomas, >> >> From: Thomas Monjalon >>> 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? >> The current proposal in rawdev could easily be supported by any hardware which supports chaining multiple functions/services into a single operation, in this case symmetric crypto and error detection, but it could conceivably support chaining symmetric/asymmetric crypto operations or chaining symmetric crypto and compression operations. >> [Fiona] Based on that logic rawdev should be deprecated. >> But the community has agreed that it has a place. > > No, as I said above, rawdev is good for SoC, FPGA management or DMA engine. I distinctly remember when rawdev was being proposed one of the uses cases proposed was that a new classes of APIs could be prototyped and developed under rawdev and when a solid consensus was reached then migrated to a mainstream DPDK library. I think every effort has been made here to engage the community to develop a generic approach. As Fiona notes there hasn't really been much of an appetite for this. Therefore I think the option to use rawdev makes sense, it allows an initial proposal to be deployed, without a generic solution agreement, it will also give others in the community to see how this approach can work and hopefully lead to more engagement on a generic solution. Also as APIs in rawdev are essentially treated as private APIs the onus is on Intel to support this going forward. > >> And the common problem here is device exposure. >> With a specialised service on top. >> >> >>>>> 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. >> >> [Fiona] Can you point me to that requirement please? > > Yes, rte_security is trying to address this exact issue. > I don't agree rte_security addresses the problem of different device types supporting the same services. The problem being addressed here is a single device which supports the chaining of multiple services (sym crypto & error detection) >> We suggested it, but did not get community engagement and have >> dropped our generic API requirement, instead focussing on this specialised case. > > I did not see such generic proposal, sorry. > >>> 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. > > >