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

Trahe, Fiona fiona.trahe at intel.com
Tue Nov 13 00:16:51 CET 2018


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.



More information about the dev mailing list