>
> Hi Konstantin,
>
> On 11/13/2018 5:19 PM, Ananyev, Konstantin wrote:
> > Hi Akhil,
> >
> >> -----Original Message-----
> >> From: Akhil Goyal [mailto:[email protected]]
> >> Sent: Tuesday, November 13, 2018 11:28 AM
> >> To: [email protected]
> >> Cc: [email protected]; Ananyev, Konstantin
> >> <[email protected]>; [email protected];
> >> [email protected]; Nicolau, Radu
> >> <[email protected]>; Doherty, Declan
> >> <[email protected]>; Hemant Agrawal
> >> <[email protected]>; Akhil Goyal <[email protected]>
> >> 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
