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 A33631D7 for ; Tue, 13 Nov 2018 00:25:00 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 15:24:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,497,1534834800"; d="scan'208";a="85320460" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga007.fm.intel.com with ESMTP; 12 Nov 2018 15:24:57 -0800 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.134]) by IRSMSX104.ger.corp.intel.com ([169.254.5.131]) with mapi id 14.03.0415.000; Mon, 12 Nov 2018 23:24:56 +0000 From: "Trahe, Fiona" To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "De Lara Guarch, Pablo" , Akhil Goyal , "Doherty, Declan" , "Ravi Kumar" , Jerin Jacob , "Zhang, Roy Fan" , Tomasz Duszynski , Hemant Agrawal , Natalie Samsonov , Dmitri Epshtein , Jay Zhou , "Trahe, Fiona" Thread-Topic: [RFC] cryptodev: proposed changes in rte_cryptodev_sym_session Thread-Index: AQHUO9Lgj4uhEYXKc0eAMj3Nvkgz2qVNEv6ggAAt8JCAAARrcA== Date: Mon, 12 Nov 2018 23:24:55 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589676F2A@IRSMSX101.ger.corp.intel.com> References: <1535132906-5167-1-git-send-email-konstantin.ananyev@intel.com> <348A99DA5F5B7549AA880327E580B43589676DA2@IRSMSX101.ger.corp.intel.com> <348A99DA5F5B7549AA880327E580B43589676F0A@IRSMSX101.ger.corp.intel.com> In-Reply-To: <348A99DA5F5B7549AA880327E580B43589676F0A@IRSMSX101.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzYyYmEwZjAtMjg1NC00MGY1LTg2NmQtNDNiNjczMzg1NDVmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiOXBaRkJ2SHFiVEhWS1pnZGZGZE5OcDYrb0dXUG9Bc2RDMXhZKzZcL1kxanlINTRERnd5UWszbXlzQ2M3Z1I3a0sifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 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] [RFC] cryptodev: proposed changes in rte_cryptodev_sym_session 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: Mon, 12 Nov 2018 23:25:01 -0000 Correction below > -----Original Message----- > From: Trahe, Fiona > Sent: Monday, November 12, 2018 4:17 PM > To: Ananyev, Konstantin ; dev@dpdk.org > Cc: De Lara Guarch, Pablo ; Akhil Goyal <= akhil.goyal@nxp.com>; > Doherty, Declan ; Ravi Kumar ; Jerin Jacob > ; Zhang, Roy Fan ; Tomasz Duszynski > ; Hemant Agrawal ; Natalie Sams= onov > ; Dmitri Epshtein ; Jay Zhou ; > Trahe, Fiona > Subject: RE: [RFC] cryptodev: proposed changes in rte_cryptodev_sym_sessi= on >=20 > RE item 4: use of session pool in qp setup: > > > 4.#2 and #3 above implies that now each struct rte_cryptodev_sym_sess= ion > > > would have sort of readonly type data (init once at allocation time= , > > > keep unmodified through session life-time). > > > That requires more changes in current cryptodev implementation: > > > Right now inside cryptodev framework both rte_cryptodev_sym_session > > > and driver specific session data are two completely different sctru= cures > > > (e.g. struct struct null_crypto_session and struct null_crypto_sess= ion). > > > Though current cryptodev implementation implicitly assumes that dri= ver > > > will allocate both of them from within the same mempool. > > > Plus this is done in a manner that they override each other fields > > > (reuse the same space - sort of implicit C union). > > > That's probably not the best programming practice, > > > plus make impossible to have readonly fields inside both of them. > > > So to overcome that situation I changed an API a bit, to allow > > > to use two different mempools for these two distinct data structure= s. > [Fiona] Ok, I can see either way on this. > Seems we could continue to use a single pool for multiple struct types as= long as the size is bigger > than the maximum. But it's also reasonable to change to two as they are u= sed so differently > - especially if that allows one to be handled as read-only after init an= d the other not - but I > didn't see any code which was doing this. > Anyway, if we go with 2 pools, I propose we remove the sess pool from the= qp config, rather than pass in > both pools. > I just did a trawl trough the PMDs and none use the sess pool - that para= m is a hangover from earlier. > A few store it in a local var, but never use it for anything. > Now is a good time to remove it. [Fiona] Correction - I found some PMDs do use it - for the sessionless case= . So I suppose we will need to pass in the two pool params.