Hi Fan, > Hi Akhil, > > > The structures rte_cryptodev_sym_session and > > rte_cryptodev_asym_session are not used by the > > application directly. The application just need > > an opaque pointer which it can attach to rte_crypto_op > > while enqueue. > > Hence, these structures can be internal to library > > hidden from the user. > > > > Signed-off-by: Akhil Goyal <gak...@marvell.com> > > --- > > v2: fixed trailing whitespace. > > > > doc/guides/rel_notes/deprecation.rst | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index f81bd87f10..c540c90f8e 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -151,6 +151,11 @@ Deprecation Notices > > * cryptodev: The APIs for interfacing between library and PMD will be > > marked > > as internal APIs in DPDK 21.11. > > > > +* cryptodev: Hide structures ``rte_cryptodev_sym_session`` and > > + ``rte_cryptodev_asym_session`` to remove unnecessary indirection > > between > > + session and the private data of session. An opaque pointer can be > exposed > > + directly to application which can be attached to the ``rte_crypto_op``. > > + > > * security: The functions ``rte_security_set_pkt_metadata`` and > > ``rte_security_get_userdata`` will be made inline functions and > > additional > > flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. > > -- > > 2.25.1 > > Have you considered how crypto scheduler PMD can support multiple crypto > devices' opaque data pointers after the change? Of course it is doable by > adding dedicated APIs to the scheduler PMD - shall I assume you will work on > it?
I haven't considered about the scheduler PMD yet. Would need your help in aligning that. The deprecation notice is to allow us change in 21.11 timeframe. Thanks, Akhil
