From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E33BAA00C2; Wed, 22 Apr 2020 16:02:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 76AD31D668; Wed, 22 Apr 2020 16:02:09 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 4AA521D64F for <dev@dpdk.org>; Wed, 22 Apr 2020 16:02:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587564127; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=jZOsbDqU5fynUVpStYS+f6zEVD6bxzPStrjX5kInWZg=; b=WnQd6S8LQHiMwsTvTzdOjeICCF+KnA411ODcL3hCX83aZ5dEQMKzKez95NtmJYMU/US5u5 5fuUnKZPPw1PAH1S1Zotr7v91kmgPty7LTynon1vG/CORiWdt851zXg0+WOSJVtWihKS2h 1g7qCJtx15myV/AP24qcTxxELIibv5c= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-91-IROb6lCAPf-ldU8YLIgVMQ-1; Wed, 22 Apr 2020 10:01:56 -0400 X-MC-Unique: IROb6lCAPf-ldU8YLIgVMQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BA8C283DB3A; Wed, 22 Apr 2020 14:01:52 +0000 (UTC) Received: from [10.33.36.244] (unknown [10.33.36.244]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9A9C5D9E2; Wed, 22 Apr 2020 14:01:46 +0000 (UTC) To: "Coyle, David" <david.coyle@intel.com>, "Doherty, Declan" <declan.doherty@intel.com>, Thomas Monjalon <thomas@monjalon.net>, "Yigit, Ferruh" <ferruh.yigit@intel.com>, "Trahe, Fiona" <fiona.trahe@intel.com> Cc: "techboard@dpdk.org" <techboard@dpdk.org>, "dev@dpdk.org" <dev@dpdk.org>, "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>, "Ryan, Brendan" <brendan.ryan@intel.com>, "shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>, "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>, "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, Anoob Joseph <anoobj@marvell.com>, Ruifeng Wang <ruifeng.wang@arm.com>, Liron Himi <lironh@marvell.com>, Nagadheeraj Rottela <rnagadheeraj@marvell.com>, Srikanth Jampala <jsrikanth@marvell.com>, Gagandeep Singh <g.singh@nxp.com>, Jay Zhou <jianjay.zhou@huawei.com>, Ravi Kumar <ravi1.kumar@amd.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, "olivier.matz@6wind.com" <olivier.matz@6wind.com>, "honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>, Stephen Hemminger <stephen@networkplumber.org>, "alexr@mellanox.com" <alexr@mellanox.com> References: <20200410142757.31508-1-david.coyle@intel.com> <4421330.vfdyTQepKt@thomas> <2fa52616-2e81-4eae-a28b-4549154742fe@intel.com> <8017884.aoefvbuG5b@thomas> <45cf0e87-2021-cc8c-82b5-60c0b1e11fb7@intel.com> <MN2PR11MB3550E8BF5E2662924C646DDFE3D50@MN2PR11MB3550.namprd11.prod.outlook.com> From: Kevin Traynor <ktraynor@redhat.com> Autocrypt: addr=ktraynor@redhat.com; keydata= mQINBF2J2awBEADUEPNhgNI+nJNgiTAUcw4YIgVXEoHlsNPyyzG1BEXkWXALy0Y3fNTiw6+r ltWDkF9jzL9kfkecgQ67itGfk1OaBXgSGKuw1PUpxAwX2Bi76LAR6M5OsyGM9TSVVQwARalz hMwRBIZPzPc7or6Pw7jAOJ8SQGJ1Zlp1YJCjrvpe87V1tH/LY8Wnxn/EuoseFmWILAQZAtYS tGjcrAgYn3SPMLR1B0BP5bTBY06vWQjiufH8drenfDnMJAzuBdG1mqjnTqCjULZ3Hunv4xqZ aMnkvL/K5Tj1c12Oe4930EE53LrXIBUltRg5mBudSWHnC7twjH0082HH9f963Z/2UI63SFIT iUvRvAzJYytgy7XnWLQ0+goZBADKYfolOuC0H8VgCaux8u8KFF28Dy+N6TV2KI58jTlyg1Zu l7QwykZpnOkJFiy37Gfbu3YEOzO72cP/S7/A+zvuqkxi63jyEkd+FY99vLt/HN2MUZwRmKDw UPbLkmrs8WU01/POVsqDcfvz7vu2St8hqqTiSIdQGS2zyTKB2/DvPSM3jws3udkIYSuhn+X4 QBiV6lkVZ7DSE6a065gnAauAql+b32Eymy+xnG5jCt1tR+0Cp2VZYCR9OU2gmomUKBDoX/He pSgED01CqYPNjN+TddirwmQX7ep4DtXc8FWvv2g/pq9WZFQk2QARAQABtCNLZXZpbiBUcmF5 bm9yIDxrdHJheW5vckByZWRoYXQuY29tPokCTgQTAQgAOBYhBAoiOaH51tHF7VYtEI9CINER a+yJBQJdidmsAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEI9CINERa+yJoxIP/3VF 2TIgW4ckxhRFCvFu/606bnvCPie88ake4uWVWMAWwcMc4fKEltRWRCpkSVOwgqoMHnyHxK5r kOKzx2CLJMX5TgTMfKzPuaBDHngHLUzl2DStpBzrod0cVg5TShdmmfjY61uxRJKz+DlSkwgJ riADdVF5PPosQXTkKSGf2ombpTGpx/pue9ocjnr3x4SDpRLlnooM6Jf/3Y3Ib4jX6HPEyWuY b+owIIk9y2nRRGPQ6jbqAhsrXd9V+77UL0QuGWloMuKMZFbNg8hbu7X5aFijAbfxj4YUgojS ba7gfGZQan8h32A9KGQWrmsCBc3j2GqEPsX0r05X7cn7WL6IOPgQJ5EiQ7PlazQYVLrvZg9B n0GKK0k6895mLG0ZZ5v/qajOPF52etSmvFD1WUPb4OqaHqGA9ZtMpaKFRt7Y6rpXqKNU1xzW F5KjbTPtTb9WF3An8dciVv+AYUI7totkZYkWvQtgss8lfaX3NKUvXLVxqK0z3dQyr7rF/tYz PneTKypSksjCgaEBLSrsRmM5zKfe7tSNF/fDntfIq/029Jtcw29TcWEP57peNu6TtejewQD9 sTI+oqiXvW2D5l7LNUDYG8eMJp2oT7I0ZSBRvwcbmjH0DtN/bXCCFfCvk8Yic68F3tV1ctix wQARVKDBhT30uCxycRWojCYqTgNJJS71uQINBF2J2awBEADP57PR2IpSYBeNSrsAjeIcsahE N4SQP2C4s50S8QEWAUhqMRI7WNv5cfeef0nDvcl1IUA6oz5SokbcsbMa+mRgaNF4N5KikWTO LPYxq2YVJoXwJ+tKmNzyOLFUIfFJ4NBJZple5dTfWzD00Dbb19Mri1hy1mWMqNTPGBee1+hw Qcp6n3mmGECvajs8G5A7NyXbwL8ihN7HX9D01ucD62b4G03yKe2g/hvKgcdUVmhCldJlF27I 2fSR9tDxH9pZqRODY4rjbFZEey/vWKXqjE+DQ8AtMSEaDfFe5D+i4Aw6erWQ3Wr+DwZt1/7G dIAElGA/q90T1ENVwJX9y7fsQssawKYYdDqURHCl5JuDXI+VXUypExipUUT5SPycMmbLsx0D iKEqPPDQWKxkIDVKqj2+EhamSuJznZUwBLJKn0h4zrIWiXWUy07lRwtVuhaDXhF3GfW+5W/x wAg7Qg3w00ASsb/XTHBIhMnenKDfS7ihtQA8SacwX8ySdxb+15XPyiplM979qBQ0mhnilulm MIJzEf/JxoYR5huuj4f1PFqqrsP06Dl+YGB7dQZp3IKggS5c3/TAynARRg9N89UsDXNtp7X0 tgIPFF5k6fnHE0J5O64GYHeTqN/1aE6dAEOV9WrGzQAJxU9ipikb8jKAWXzLewRIKGmoPcRZ WdB0NmIjmQARAQABiQI2BBgBCAAgFiEECiI5ofnW0cXtVi0Qj0Ig0RFr7IkFAl2J2awCGwwA CgkQj0Ig0RFr7IkkORAAl/NbX93WK5MEoRw7/DaPTo/Lo6Pj1XMeSqGyACigHK/452UDvlEH NjNJMzYYrNIjMtEmN9VVCfjT38CSca7mpGQVwchc0mC7QSPAETLCS+UacVf/Kwxz5FfkEUUw UT7A+uyVOIgW3d9ldlRzkHA2czonSSgTQU+i2g6DM4ha+BuQb4byAXH6HQHt/Zh1J64z0ohH v6iGsCzCY/sMWF8+LEGSnzMGRCLiiwSF0vJBHbzWK68fANaF4gBV0Z/+6tQRFN7YMhj/INmk qgvHj1ZzHFNtirjMGPRxoZs51YoLQM/aBPxKrnmXThx1ufH+0L6sGmFTugiDt0XSEkC5reH7 a+VhQ1VTFFQrClA8NmDSPzFeuhru4ryaaDHO+uEB16cNHxHrQtlP/2hts2JM5lwkZRWJ5A57 h8eDEIK5be47T85NVHfuTaboNRmgg1HygVejhGUtt69u/0MVRg/roUTa0FyEbNsvz4qAecyW yWzMcVrcGJDQLC9JLKEpoyUF6gdTKaiDL2Vao4+XRIA3Y57b6MO35a3HuzAv7+i5Z0mnDEJO XxXqTOmKYpMIGexzM/PtuA0712sT1abG9tAJ17ao/B7cqMW5IkKkalemFbWfI2unns4Papvo tk9igVqyp6EJDU98z5TJioCVojwK2laDaoIjTJk9YYv3iwCsqPd5feU= Message-ID: <f7c0320c-e418-613f-9e28-2347effba612@redhat.com> Date: Wed, 22 Apr 2020 15:01:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <MN2PR11MB3550E8BF5E2662924C646DDFE3D50@MN2PR11MB3550.namprd11.prod.outlook.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Hi David, On 21/04/2020 18:23, Coyle, David wrote: > Thank you Thomas for your input. >=20 > We would like to request that the Tech-Board (CC'ed) also review the prop= osal to help us reach a consensus. > =20 The discussion on the mailing list still looks active and I think that's where it should continue until there is no reasonable hope of consensus. I'm not sure discussing over irc at TB will find a better technical solution. > If the current proposal is not acceptable, we would welcome feedback from= the board on how to rework our > proposal to something that would be acceptable. > =20 > For the benefit of the Tech-Board here is the back-ground to our proposal= for Rawdev-based multi-function > processing: > - The primary objective is to support the AESNI MB combined Crypto-CRC pr= ocessing capability in DPDK and > in future to add support for combined Crypto-CRC support in QAT. > - The cryptodev API was considered unsuitable because CRC is not a crypto= graphic operation, and this would > also preclude other non-crypto operations in the future such as compre= ssion. > - The rte_security API was also not considered suitable for chaining of n= on-crypto operations such as CRC, > as Declan pointed out below. > - A new Accelerator API was proposed as an RFC but was not pursued due to= community feedback that a > new API would not be welcome for a single use-case. > - Using Rawdev for multi-function processing was then proposed and, initi= ally, as there was no opposition > we implemented a patch-set for this approach. > =20 > It was considered that a Rawdev-based multi-function approach would be su= itable for the following reasons: > 1) Multi-function processing for Crypto-CRC cases is not a good fit for a= ny of the existing DPDK classes. > 2) Rawdev was intended for such specialized acceleration processing that = are not a good fit for existing DPDK > classes. > 3) Rawdev was also intended as somewhere that new use-cases like this cou= ld be prototyped and developed, > such as Declan mentions below > 4) The Rawdev-based multi-function proposal is extensible and we would ho= pe that it can evolve to support > new use-cases and target new devices in the future with the communit= ies involvement. >=20 This is a useful summary and explaining your approach but it doesn't mention the counter arguments, so it doesn't seem balanced. Of course people can read that in the ML thread. Kevin. >=20 >> -----Original Message----- >> From: Doherty, Declan <declan.doherty@intel.com> >> Sent: Tuesday, April 21, 2020 5:46 PM >> >> On 15/04/2020 11:33 PM, Thomas Monjalon wrote: >>> 16/04/2020 00:19, Doherty, Declan: >>>> On 14/04/2020 3:44 PM, Thomas Monjalon wrote: >>>>> 14/04/2020 16:02, Trahe, Fiona: >>>>>> From: Thomas Monjalon <thomas@monjalon.net> >>>>>>> 14/04/2020 15:04, Trahe, Fiona: >>>>>>>>> 14/04/2020 12:21, Ferruh Yigit: >>>>>>>>> >>>>>>> >> http://inbox.dpdk.org/dev/MN2PR11MB35507D4B96677A41E66440C5E3C30 >> @M >>>>>>> N2PR11MB3550.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. >>> >>> Because hardware support is pending, >>> we should accept an Intel-only "temporary" solution, opening the door >>> to more vendor-specific APIs? >>> >>> What is the benefit for the DPDK project? >>> >> Sorry I don't agree with this sentiment, David has made every attempt to >> solicit feedback and to engage the community in this. >> >> I also don't agree in classifying this as a "temporary solution" as this= is a solid >> proposal for an approach to chaining multiple operations together, but I >> guess the fact remains that we only currently have a single use-case, bu= t it is >> difficult to generate a generic solution in this case. >> >> While there is only a single use case it is targeting two devices so tha= t drove >> the need for a common interface within rawdev. >> >> The advantage of using rawdev is that it allows this to be consumed thro= ugh >> DPDK, which enables DPDK project consumers, but also leaves the door ope= n >> to other contributors to have their say on how this should evolve. For >> example this exact process seems to be occurring with DMA engines in >> rawdev today, with a critical mass of implementations which now is givin= g the >> impetus to create a generic solution, as we would hope can occur here to= o in >> the future. >> >> >>>>>> 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) >>> >>> Doing IPsec processing in Rx or Tx of a NIC is not chaining? >>> >> I wouldn't consider an inline crypto offload or full IPsec offload a cha= ined >> operation in the vein being proposed here where completely independent >> services (in the view of DPDK which are currently on independent devices >> and APIs) are linked together. >> >> We did look at using rte_security here but it wasn't considered suitable= for a >> chaining of non-crypto operations such as CRC or possibly compression in= the >> future, as it would still run into the issue of having to use the crypto= dev >> enq/deq API in the lookaside offload case. >> >> >>>>>> 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. >>> >>> >>>