From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id BF1A65B12 for ; Tue, 13 Mar 2018 20:18:50 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2018 12:18:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,466,1515484800"; d="scan'208";a="25359592" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga006.jf.intel.com with ESMTP; 13 Mar 2018 12:18:46 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.9]) by IRSMSX151.ger.corp.intel.com ([169.254.4.16]) with mapi id 14.03.0319.002; Tue, 13 Mar 2018 19:18:45 +0000 From: "De Lara Guarch, Pablo" To: "Luse, Paul E" , Thomas Monjalon CC: "dev@dpdk.org" , "Doherty, Declan" Thread-Topic: [dpdk-dev] Question on AESNI PMD Thread-Index: AdO38lpOBr50FV93SX6Y0kvlI3FInQAAM7ZgAADzWYAAt7m6gAAG8AUQ Date: Tue, 13 Mar 2018 19:18:44 +0000 Message-ID: References: <82C9F782B054C94B9FC04A331649C77AA6ABA2B4@fmsmsx104.amr.corp.intel.com> <6138797.4gfP7HpVFi@xps> <82C9F782B054C94B9FC04A331649C77AA6ABEFF1@fmsmsx104.amr.corp.intel.com> In-Reply-To: <82C9F782B054C94B9FC04A331649C77AA6ABEFF1@fmsmsx104.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjA5Y2FlNzEtM2E0NC00MDY3LTg1YmQtNDA1NjI5NTlkMGY3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImZZWUZWXC9wR1wvNVwvZlBZSklPaE4zY3lFNTVmNFkrSjNaYTBOR1RCYkM2TXM9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Question on AESNI PMD 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, 13 Mar 2018 19:18:51 -0000 Hi Paul, Apologies for the delay. Answers inline. > -----Original Message----- > From: Luse, Paul E > Sent: Tuesday, March 13, 2018 2:16 PM > To: Thomas Monjalon > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > Subject: RE: [dpdk-dev] Question on AESNI PMD >=20 > Any thoughts on this? >=20 > Thanks, > Paul >=20 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Friday, March 9, 2018 3:36 PM > To: Luse, Paul E > Cc: dev@dpdk.org; De Lara Guarch, Pablo > ; Doherty, Declan > > Subject: Re: [dpdk-dev] Question on AESNI PMD >=20 > Cc Declan and Pablo, the maintainers >=20 > 09/03/2018 23:08, Luse, Paul E: > > Hi, > > > > I'm working on an SPDK module that uses the DPDK cryptodev > framework, initially I'm using the AESNI PMD and have a few questions. in > the doc it says that only in-place is supported however I see code in > set_mb_job_params() just after the comment "Mutable crypto operation > parameters" it appears to support a separate src and dst m_buf so curious > about that. > > > > For my use case (storage) I'm using external data buffers so I can't us= e > that code anyways but I was able to make some minor changes and am able > to pass in different src and dst m_bufs that point to my own data buffers > (not in the packet) and it seems to be working fine. > > > > So my 2 questions are: > > > > (1) is the documented in-place limitation simply not correct? You are right, it looks like it is not correct. I need to make sure if the feature is fully supported and we can remove the= limitation. > > > > (2) would there be any upstream interest in supporting a patch that > enables m_bufs using external data buffers for src and dst? Do you mean src and dst using different containers (non mbufs), or using mbufs which data is pointing at another location? The first would impact all PMDs and would introduce complexity (plus that w= ould mean an API breakage), that might be unnecessary, whereas the second one is possible to do it from= an application point of view (without changing the API). Thanks, Pablo > > > > Thanks! > > Paul >=20 >=20 >=20 >=20