Re: [dpdk-dev] [PATCH] security: remove experimental tag

[Akhil Goyal <akhil.goyal@nxp.com>]

> 
> Hi Konstantin,
> 
> On 11/13/2018 5:19 PM, Ananyev, Konstantin wrote:
> > Hi Akhil,
> >
> >> -----Original Message-----
> >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> >> Sent: Tuesday, November 13, 2018 11:28 AM
> >> To: dev@dpdk.org
> >> Cc: thomas@monjalon.net; Ananyev, Konstantin 
> >> <konstantin.ananyev@intel.com>; jerin.jacob@caviumnetworks.com; 
> >> anoob.joseph@caviumnetworks.com; Nicolau, Radu 
> >> <radu.nicolau@intel.com>; Doherty, Declan 
> >> <declan.doherty@intel.com>; Hemant Agrawal 
> >> <hemant.agrawal@nxp.com>; Akhil Goyal <akhil.goyal@nxp.com>
> >> Subject: [PATCH] security: remove experimental tag
> >>
> >> rte_security has been experimental since DPDK 17.11 release.
> >> Now the library has matured and expermental tag is removed in this 
> >> patch.
> > I agree that it is present for a while in dpdk.org, but as I can see 
> > we still have unimplemented API here.
> > Which makes me doubt that it is ok to remove experimental tag from it.
> > Konstantin
> 3 vendors(Intel/Cavium/NXP) have tested their PMDs on security and 
> made the changes that they need.
> Which APIs are missing? 

What I am aware about:
a) rte_security_ops. get_userdata
[Akhil] I believe Cavium added some patches in ipsec-secgw app for its usage and I believe they do have implementation for that. Also I cannot see any changes in rte_security for its support in PMDs.

b) RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL

[Akhil] Cavium supports it.

c) rte_security_capability.ol_flags:
    RTE_SECURITY_PDCP_ORDERING_CAP
    RTE_SECURITY_PDCP_DUP_DETECT_CAP

[Akhil] PDCP is not currently supported by any of the vendors except NXP and NXP do not support these capabilities.
For this also, I don’t see any change in the library. It would be only PMD which needs to support it.

    RTE_SECURITY_TX_HW_TRAILER_OFFLOAD
    RTE_SECURITY_RX_HW_TRAILER_OFFLOAD

[Akhil] Same here, these are all PMD capabilities which do not require any change in rte_security.

>I believe addition of protocols is not an issue  even if we remove 
>experimental tag.

After another thought - it is probably unfair to keep whole lib as experimental because few things are missing.
But I think things that are unimplemented (or related to them) need to stay in 'experimental' state.

[Akhil] I do not foresee any changes in library, so I believe experimental is not required. Please correct me if this is incorrect understanding.

Konstantin

> 
> -Akhil