>
> Hi Konstantin,
>
> On 11/13/2018 5:19 PM, Ananyev, Konstantin wrote:
> > Hi Akhil,
> >
> >> -----Original Message-----
> >> From: Akhil Goyal [mailto:akhil.go...@nxp.com]
> >> Sent: Tuesday, November 13, 2018 11:28 AM
> >> To: dev@dpdk.org
> >> Cc: tho...@monjalon.net; Ananyev, Konstantin
> >> <konstantin.anan...@intel.com>; jerin.ja...@caviumnetworks.com;
> >> anoob.jos...@caviumnetworks.com; Nicolau, Radu
> >> <radu.nico...@intel.com>; Doherty, Declan
> >> <declan.dohe...@intel.com>; Hemant Agrawal
> >> <hemant.agra...@nxp.com>; Akhil Goyal <akhil.go...@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
