[dpdk-dev] [PATCH] doc: security deprecation notice for session changes

[Ananyev, Konstantin]

> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal at nxp.com]
> Sent: Wednesday, November 14, 2018 12:40 PM
> To: Ananyev, Konstantin <konstantin.ananyev at intel.com>; dev at dpdk.org
> Cc: Doherty, Declan <declan.doherty at intel.com>
> Subject: Re: [dpdk-dev] [PATCH] doc: security deprecation notice for session changes
> 
> 
> 
> On 11/14/2018 4:53 PM, Konstantin Ananyev wrote:
> > Add 'uint64_t opaque_data' inside struct rte_security_session.
> > That allows upper layer to easily associate some user defined
> > data with the session.
> > Proposed new layout for:
> > struct rte_security_session {
> > 	void *sess_private_data;
> > 	/**< Private session material */
> > +	uint64_t opaque_data;
> > +	/**< Opaque user defined data */
> > };
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev at intel.com>
> > ---
> Acked-by: Akhil Goyal <akhil.goyal at nxp.com>
> 
> Does this also mean you have given the Ack for removing the experimental
> tag from security library? Because otherwise there is no point of this
> deprecation notice if the library is not formal.

For the whole library - yes.
Though I still suggest to keep 'experimental' for non-implemented functions
(rte_security_get_userdata()).
Hope that wouldn't block you guys.
Konstantin 

> >   doc/guides/rel_notes/deprecation.rst | 6 ++++++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> > index 34b28234c..0cdc42842 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -55,3 +55,9 @@ Deprecation Notices
> >     - ``rte_pdump_set_socket_dir`` will be removed;
> >     - The parameter, ``path``, of ``rte_pdump_init`` will be removed;
> >     - The enum ``rte_pdump_socktype`` will be removed.
> > +
> > +* security: ABI change:
> > +
> > +  New field ``uint64_t opaque_data`` is planned to add into
> > +  ``rte_security_session`` structure. That would allow upper layer to easily
> > +  associate/de-associate some user defined data with the security session.