[dpdk-dev] [RFC] cryptodev: proposed changes in rte_cryptodev_sym_session

[Trahe, Fiona]

Correction below

> -----Original Message-----
> From: Trahe, Fiona
> Sent: Monday, November 12, 2018 4:17 PM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; dev at dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>; Akhil Goyal <akhil.goyal at nxp.com>;
> Doherty, Declan <declan.doherty at intel.com>; Ravi Kumar <ravi1.kumar at amd.com>; Jerin Jacob
> <jerin.jacob at caviumnetworks.com>; Zhang, Roy Fan <roy.fan.zhang at intel.com>; Tomasz Duszynski
> <tdu at semihalf.com>; Hemant Agrawal <hemant.agrawal at nxp.com>; Natalie Samsonov
> <nsamsono at marvell.com>; Dmitri Epshtein <dima at marvell.com>; Jay Zhou <jianjay.zhou at huawei.com>;
> Trahe, Fiona <fiona.trahe at intel.com>
> Subject: RE: [RFC] cryptodev: proposed changes in rte_cryptodev_sym_session
> 
> RE item 4: use of session pool in qp setup:
> > > 4.#2 and #3 above implies that now each struct rte_cryptodev_sym_session
> > >   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 sctrucures
> > >   (e.g. struct struct null_crypto_session and struct null_crypto_session).
> > >   Though current cryptodev implementation implicitly assumes that driver
> > >   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.
> 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 used 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 qp 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.
> 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.