From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Trahe, Fiona" Subject: Re: [RFC] cryptodev: proposed changes in rte_cryptodev_sym_session Date: Mon, 12 Nov 2018 23:16:51 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589676F0A@IRSMSX101.ger.corp.intel.com> References: <1535132906-5167-1-git-send-email-konstantin.ananyev@intel.com> <348A99DA5F5B7549AA880327E580B43589676DA2@IRSMSX101.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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" To: "Ananyev, Konstantin" , "dev@dpdk.org" Return-path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 353801D7 for ; Tue, 13 Nov 2018 00:16:56 +0100 (CET) In-Reply-To: <348A99DA5F5B7549AA880327E580B43589676DA2@IRSMSX101.ger.corp.intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" RE item 4: use of session pool in qp setup: > > 4.#2 and #3 above implies that now each struct rte_cryptodev_sym_sessio= n > > 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 sctrucu= res > > (e.g. struct struct null_crypto_session and struct null_crypto_sessio= n). > > Though current cryptodev implementation implicitly assumes that drive= r > > 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 structures. [Fiona] Ok, I can see either way on this.=20 Seems we could continue to use a single pool for multiple struct types as l= ong as the size is bigger than the maximum. But it's also reasonable to change to two as they are use= d so differently - especially if that allows one to be handled as read-only after init and = 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 q= p config, rather than pass in both pools. I just did a trawl trough the PMDs and none use the sess pool - that param = is a hangover from earlier. A few store it in a local var, but never use it for anything.=20 Now is a good time to remove it.