From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 15:16:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,497,1534834800"; d="scan'208";a="107699741" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga001.jf.intel.com with ESMTP; 12 Nov 2018 15:16:53 -0800 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX153.ger.corp.intel.com (163.33.192.75) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 12 Nov 2018 23:16:52 +0000 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.134]) by irsmsx155.ger.corp.intel.com ([169.254.14.44]) with mapi id 14.03.0415.000; Mon, 12 Nov 2018 23:16:51 +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: AQHUO9Lgj4uhEYXKc0eAMj3Nvkgz2qVNEv6ggAAt8JA= 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> In-Reply-To: <348A99DA5F5B7549AA880327E580B43589676DA2@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:16:57 -0000 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.