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 E970EA0598; Tue, 21 Apr 2020 20:37:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C36181D412; Tue, 21 Apr 2020 20:37:25 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 30A531C43D for ; Tue, 21 Apr 2020 20:37:22 +0200 (CEST) IronPort-SDR: jd93YIN/ZEJMUiGm126PAs4bmQDUqWwqtO4xfZ9JeQQ4KCyHp40Tt6WQFVxVq1QkJFaElCxXLo xKuHYj8NVkaA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2020 11:37:21 -0700 IronPort-SDR: pkmKSSOf1LGixoJCZotRLzw3MChGBM3BtEbMVlflS25prGWmkdKTTEdPriAKjg5NdzVhD+mtSt Bap+DftWsVCA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,411,1580803200"; d="scan'208";a="279742912" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga004.fm.intel.com with ESMTP; 21 Apr 2020 11:37:20 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Apr 2020 11:37:21 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Apr 2020 11:37:21 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.169) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Apr 2020 11:37:20 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nMHA2nHWP75QaAO5TviaCZwlQaVhW+08sr6V/9BR2lbTcokOxVv2/jjWXi1OHydhJ0HbU6NV/S0v5mGuIXg3Bnjhps78PEqR7q23CpARyOgQ6arR0jnUjM9Q9twiv0+OhMng7anVU59mI/fB1o/hB+3hA2nTlhX2NIbNe/hIu0dmJr7k/6LrUutyUJahaxjIfDXeM2xso/KEczmk18fLYBKh4XANOKtfCvSJjOzWW+S+znPpY3yRVwS8t2i6CinDUWtvf/d3ddG8g7xmR4fPfLBSDGJ14PZBzsZZou8w5tJaSQloFVN+GvrKvXBvr3nwuOiyyos+soSPUpBxuo7R8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pG15WoHb1P2C4V+YHp/C3Z9rOkBn1j4XeyFy1X8Vi1w=; b=hDd/Asqy+clJVMmyd0L+bluNLCU3wbSKQun7Rx2dzwtLVEREgdM6JfMc4f7yxIvmvwBTaMBP5HqsVwtCUEutY8hP2cXlyJLC6satmNzKp6ZueVg1XkiCpecj2R7bRq/wpyNlsr5X18CUptN6hp9ZL0IGilKGqsHsDvuzBBx0gJq/xxkKyPFDAExKhz5FhpAQm7umGwIEkoX3vj4nYiO/NOmvriAyoiEiAIag1LhNDjiCzqqEFAUZkSpJl12MwHYkr3xMvyMg+VmQjYJls7vdXyWK/iIADFyalY8cyuYiQP3ecpS3WVkauIGSZclQyCUsV9Owv3mz5TYaSeY1QOQePA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pG15WoHb1P2C4V+YHp/C3Z9rOkBn1j4XeyFy1X8Vi1w=; b=MWwWfdLJ4S4uivy6zshMKkOyYXvsQ+RWVG4yPAojO3qBrBmlSDJwaPO/tS8Dha7FC9NaPX9WYkcyIJZ1bQBh9XCXkVCjOgHRbBX842k57crruyc8aANi4+0+fB1TVZDylTY8naOSZPvz4X3yMIl/g4/drQgC5EpFidSt9xkvYPE= Received: from MN2PR11MB3550.namprd11.prod.outlook.com (2603:10b6:208:ee::21) by MN2PR11MB4045.namprd11.prod.outlook.com (2603:10b6:208:135::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Tue, 21 Apr 2020 18:37:14 +0000 Received: from MN2PR11MB3550.namprd11.prod.outlook.com ([fe80::8418:9aea:e601:4470]) by MN2PR11MB3550.namprd11.prod.outlook.com ([fe80::8418:9aea:e601:4470%6]) with mapi id 15.20.2937.012; Tue, 21 Apr 2020 18:37:14 +0000 From: "Coyle, David" To: Thomas Monjalon , "Doherty, Declan" CC: "Yigit, Ferruh" , "Trahe, Fiona" , "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" , "olivier.matz@6wind.com" , "honnappa.nagarahalli@arm.com" , Stephen Hemminger , "alexr@mellanox.com" , "jerinj@marvell.com" , Pavan Nikhilesh Thread-Topic: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing Thread-Index: AQHWD0YSKRAUuvHdZUmfm4csrp+okahy99iAgAV2poCAAALdAIAAKoOAgAAFkQCAAArIAIAAC6GAgAIRlQCAAAO0gIAJDR2AgAAK3wCAAA/REA== Date: Tue, 21 Apr 2020 18:37:13 +0000 Message-ID: References: <20200410142757.31508-1-david.coyle@intel.com> <8017884.aoefvbuG5b@thomas> <45cf0e87-2021-cc8c-82b5-60c0b1e11fb7@intel.com> <1617700.QkHrqEjB74@thomas> In-Reply-To: <1617700.QkHrqEjB74@thomas> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.2.0.6 dlp-product: dlpe-windows authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.coyle@intel.com; x-originating-ip: [192.198.151.165] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 11e2e3fb-a5d9-48ae-6524-08d7e62302c6 x-ms-traffictypediagnostic: MN2PR11MB4045: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 038002787A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3550.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(39860400002)(366004)(396003)(346002)(136003)(376002)(186003)(86362001)(478600001)(52536014)(9686003)(26005)(55016002)(45080400002)(54906003)(110136005)(7416002)(7696005)(33656002)(6636002)(966005)(64756008)(66556008)(66476007)(81156014)(6506007)(8676002)(8936002)(316002)(66946007)(71200400001)(2906002)(76116006)(53546011)(4326008)(66446008)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0gQxQn3oKdFoy9+53PayicFuPk+TJNC5bEsZ1bd5d07cIxZxor3uKBsVm2O8Jusznld4K9Je6keufLHkTt5wFgBzcGJbe2AghtU2IHwrFPHYVF4Q+z8zk6gTQhUaz7e6HRGMouLdr91QmUIMxj0IDSH76Pe+4UW5UuOAGxuSe9K4CrIdKPm7Pvz3SWQwJAG7lMJIB86C8/DQV3XkQp7RG+JbHH6pIWkblqIAcQdUaZo4eCbwyVS4A0zogZX28SvynwmVBJ5jJPddsXOlpxC1OPAQUcCNHMnKoEs3OIRM4hmU34SL4zUYh5Wz8iaq79ImmAHdqRa+e6hj7DUt2PEt6TGKWlaG9f6hq86qXjWBdZxH6KP8KiiLHlTHuEzr71sZhqIoC4f36ayT2RMHveY9d+VrKr8fml2gZFkkG9Di0sHubMXjc+PsxWAYHouo0kOz+sNTMhSeFdkcWxqEuaLJnofRen+jgmGJ3IKoi8WK13cJjK8OpiI9ntmfWqHoWHjGI1cA/yDARnH8edZFDilrsg== x-ms-exchange-antispam-messagedata: tS6n7fczoMordxe/COScE9eSzZpx7Z6d7y8edquZ+j2tkl8O1ihmwAOdVA0wh1d6qfLrW/tWkrhphjh5dwx4OR48Vru/fLIrsSMLZluPty6WVX4gCI9yuh4TByKFGEaxoH2j9oxv0Pag2o/QT6Nzmw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 11e2e3fb-a5d9-48ae-6524-08d7e62302c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 18:37:13.9245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: c8AoDT4CVvFU6APOxuSsfYe+acIab9ccHTziuqfsHxKDjII6vgvo7skG0vqvM1k1Wym9LUiExN63yXHN8OAjHw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4045 X-OriginatorOrg: intel.com 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Tuesday, April 21, 2020 6:25 PM [PATCH v3 0/4] add AESNI-MB rawdev for multi- > function processing >=20 > 21/04/2020 18:46, Doherty, Declan: > > 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 > > >>>>> 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. > > > > > > 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 an to engage the community in this. >=20 > Really? >=20 > These are the recipients of the first patch: > dev@dpdk.org, declan.doherty@intel.com, fiona.trahe@intel.com In > next patches, only Intel and NXP are Cc'ed. > Stephen and Jerin, who gave good comments on first patch, were not Cc'ed > in next versions. >=20 > Was it presented in an event? > Was it brought to the techboard? > Please don't exagerate and admit you are trying to push something which i= s > specific and convenient for Intel QuickAssist. [DC] This is being brought to the TechBoard tomorrow (22/04) >=20 >=20 > > 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, but 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 > > that drove the need for a common interface withing rawdev. > > > > The advantage of using rawdev is that it allows this to be consumed > > through DPDK, which enables DPDK project consumers, but also leaves > > the door open 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 giving the impetus to create a generic > > solution, as we would hope can occur here too 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 > > chained 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 cryptodev enq/deq API in the lookaside offlo= ad > case. >=20 > Because rte_security is not a generic solution (that's why I don't like i= t). > I think a good approach would be to check how to offload in HW the chaini= ng > done in frameworks like rte_pipeline or rte_graph. > Stephen and Jerin already talked about it, but it was rejected by David, > because harder to implement I think. > Even worst, the team working on this patch did zero review of rte_graph. [DC] The team working on this patch did review rte_graph and explained our = reasoning to Jerin as to why we felt it was not suitable. While Jerin explained it would be possible to combine 2 nodes as a single o= ptimized node at runtime, he also agreed that it did NOT make sense to abstract what we are trying to= do as a graph. Please see http://mails.dpdk.org/archives/dev/2020-March/159238.html >=20 > I think the chaining requirement is a real problem to solve, and it deser= ves a > good architecture and API. > Maybe this future API should be based on rte_graph. >=20