> -----Original Message-----
> From: Trahe, Fiona
> Sent: Monday, November 12, 2018 11:25 PM
> To: Ananyev, Konstantin <konstantin.anan...@intel.com>; dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; Akhil Goyal
> <akhil.go...@nxp.com>; Doherty, Declan
> <declan.dohe...@intel.com>; Ravi Kumar <ravi1.ku...@amd.com>; Jerin Jacob
> <jerin.ja...@caviumnetworks.com>; Zhang, Roy Fan
> <roy.fan.zh...@intel.com>; Tomasz Duszynski <t...@semihalf.com>; Hemant
> Agrawal <hemant.agra...@nxp.com>; Natalie Samsonov
> <nsams...@marvell.com>; Dmitri Epshtein <d...@marvell.com>; Jay Zhou
> <jianjay.z...@huawei.com>; Trahe, Fiona
> <fiona.tr...@intel.com>
> Subject: RE: [RFC] cryptodev: proposed changes in rte_cryptodev_sym_session
>
> Correction below
>
> > -----Original Message-----
> > From: Trahe, Fiona
> > Sent: Monday, November 12, 2018 4:17 PM
> > To: Ananyev, Konstantin <konstantin.anan...@intel.com>; dev@dpdk.org
> > Cc: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com>; Akhil Goyal
> > <akhil.go...@nxp.com>;
> > Doherty, Declan <declan.dohe...@intel.com>; Ravi Kumar
> > <ravi1.ku...@amd.com>; Jerin Jacob
> > <jerin.ja...@caviumnetworks.com>; Zhang, Roy Fan <roy.fan.zh...@intel.com>;
> > Tomasz Duszynski
> > <t...@semihalf.com>; Hemant Agrawal <hemant.agra...@nxp.com>; Natalie
> > Samsonov
> > <nsams...@marvell.com>; Dmitri Epshtein <d...@marvell.com>; Jay Zhou
> > <jianjay.z...@huawei.com>;
> > Trahe, Fiona <fiona.tr...@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.
Yes, we need it for sessionless op.
Konstantin
