[v5,2/2] cryptodev: version cryptodev info get function
Checks
Commit Message
This patch adds versioned function rte_cryptodev_info_get()
to prevent some issues with ABI policy.
Node v21 works in same way as before, returning driver capabilities
directly to the API caller. These capabilities may include new elements
not part of the v20 ABI.
Node v20 function maintains compatibility with v20 ABI releases
by stripping out elements not supported in v20 ABI. Because
rte_cryptodev_info_get is called by other API functions,
rte_cryptodev_sym_capability_get function is versioned the same way.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
v2:
- changed version numbers of symbols to 20.0.2
v3:
- added v2/v3 informations
- changed version numbers of symbols to 21
v4:
- fixed clang build by movind binding default symbol
- implemented mailing list comments
- added abidiff tool suppression entries
v5:
- fixed meson build
devtools/libabigail.abignore | 8 ++
lib/librte_cryptodev/meson.build | 1 +
lib/librte_cryptodev/rte_cryptodev.c | 147 ++++++++++++++++++++++++-
lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
5 files changed, 191 insertions(+), 6 deletions(-)
Comments
On 07/05/2020 11:57, Arek Kusztal wrote:
> This patch adds versioned function rte_cryptodev_info_get()
> to prevent some issues with ABI policy.
> Node v21 works in same way as before, returning driver capabilities
> directly to the API caller. These capabilities may include new elements
> not part of the v20 ABI.
> Node v20 function maintains compatibility with v20 ABI releases
> by stripping out elements not supported in v20 ABI. Because
> rte_cryptodev_info_get is called by other API functions,
> rte_cryptodev_sym_capability_get function is versioned the same way.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> ---
> v2:
> - changed version numbers of symbols to 20.0.2
> v3:
> - added v2/v3 informations
> - changed version numbers of symbols to 21
> v4:
> - fixed clang build by movind binding default symbol
> - implemented mailing list comments
> - added abidiff tool suppression entries
> v5:
> - fixed meson build
>
> devtools/libabigail.abignore | 8 ++
> lib/librte_cryptodev/meson.build | 1 +
> lib/librte_cryptodev/rte_cryptodev.c | 147 ++++++++++++++++++++++++-
> lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
> lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
> 5 files changed, 191 insertions(+), 6 deletions(-)
>
[SNIP]
Acked-by: Ray Kinsella <mdr@ashroe.eu>
> -----Original Message-----
> From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
> Sent: Thursday, May 7, 2020 11:57 AM
> To: dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; Kinsella, Ray <ray.kinsella@intel.com>;
> akhil.goyal@nxp.com; Richardson, Bruce <bruce.richardson@intel.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>
> Subject: [PATCH v5 2/2] cryptodev: version cryptodev info get function
>
> This patch adds versioned function rte_cryptodev_info_get()
> to prevent some issues with ABI policy.
> Node v21 works in same way as before, returning driver capabilities
> directly to the API caller. These capabilities may include new elements
> not part of the v20 ABI.
> Node v20 function maintains compatibility with v20 ABI releases
> by stripping out elements not supported in v20 ABI. Because
> rte_cryptodev_info_get is called by other API functions,
> rte_cryptodev_sym_capability_get function is versioned the same way.
>
> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Hi Ray/Arek,
I still see Incompatible cryptodev even after update in the abignore list.
I checked it with ./devtools/validate-abi.sh
NOTICE: ABI may be incompatible, check reports/logs for details.
NOTICE: Incompatible list: librte_cryptodev.so
Did I miss something?
>
> On 07/05/2020 11:57, Arek Kusztal wrote:
> > This patch adds versioned function rte_cryptodev_info_get()
> > to prevent some issues with ABI policy.
> > Node v21 works in same way as before, returning driver capabilities
> > directly to the API caller. These capabilities may include new elements
> > not part of the v20 ABI.
> > Node v20 function maintains compatibility with v20 ABI releases
> > by stripping out elements not supported in v20 ABI. Because
> > rte_cryptodev_info_get is called by other API functions,
> > rte_cryptodev_sym_capability_get function is versioned the same way.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> > v2:
> > - changed version numbers of symbols to 20.0.2
> > v3:
> > - added v2/v3 informations
> > - changed version numbers of symbols to 21
> > v4:
> > - fixed clang build by movind binding default symbol
> > - implemented mailing list comments
> > - added abidiff tool suppression entries
> > v5:
> > - fixed meson build
> >
> > devtools/libabigail.abignore | 8 ++
> > lib/librte_cryptodev/meson.build | 1 +
> > lib/librte_cryptodev/rte_cryptodev.c | 147
> ++++++++++++++++++++++++-
> > lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
> > lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
> > 5 files changed, 191 insertions(+), 6 deletions(-)
> >
> [SNIP]
>
> Acked-by: Ray Kinsella <mdr@ashroe.eu>
Hi Akhil,
I didn't see this - checking again.
Ray K
On 09/05/2020 22:11, Akhil Goyal wrote:
> Hi Ray/Arek,
>
> I still see Incompatible cryptodev even after update in the abignore list.
> I checked it with ./devtools/validate-abi.sh
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list: librte_cryptodev.so
>
> Did I miss something?
>
>
>>
>> On 07/05/2020 11:57, Arek Kusztal wrote:
>>> This patch adds versioned function rte_cryptodev_info_get()
>>> to prevent some issues with ABI policy.
>>> Node v21 works in same way as before, returning driver capabilities
>>> directly to the API caller. These capabilities may include new elements
>>> not part of the v20 ABI.
>>> Node v20 function maintains compatibility with v20 ABI releases
>>> by stripping out elements not supported in v20 ABI. Because
>>> rte_cryptodev_info_get is called by other API functions,
>>> rte_cryptodev_sym_capability_get function is versioned the same way.
>>>
>>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>> ---
>>> v2:
>>> - changed version numbers of symbols to 20.0.2
>>> v3:
>>> - added v2/v3 informations
>>> - changed version numbers of symbols to 21
>>> v4:
>>> - fixed clang build by movind binding default symbol
>>> - implemented mailing list comments
>>> - added abidiff tool suppression entries
>>> v5:
>>> - fixed meson build
>>>
>>> devtools/libabigail.abignore | 8 ++
>>> lib/librte_cryptodev/meson.build | 1 +
>>> lib/librte_cryptodev/rte_cryptodev.c | 147
>> ++++++++++++++++++++++++-
>>> lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
>>> lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
>>> 5 files changed, 191 insertions(+), 6 deletions(-)
>>>
>> [SNIP]
>>
>> Acked-by: Ray Kinsella <mdr@ashroe.eu>
Hi Akhil,
So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
which does not use libabigail.ignore.
So you will end up with different results compared to using libabigail as follows:
DPDK_ABI_REF_DIR=<some absolute path> DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh
I did check with the "ABI Compliance Checker" (I like this tool also), however I got the following
NOTICE: No error detected, ABI is compatible.
INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports directory
What references did you use with validate-abi.sh (I used v20.02 and HEAD).
Ray K
On 09/05/2020 22:11, Akhil Goyal wrote:
> Hi Ray/Arek,
>
> I still see Incompatible cryptodev even after update in the abignore list.
> I checked it with ./devtools/validate-abi.sh
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list: librte_cryptodev.so
>
> Did I miss something?
>
>
>>
>> On 07/05/2020 11:57, Arek Kusztal wrote:
>>> This patch adds versioned function rte_cryptodev_info_get()
>>> to prevent some issues with ABI policy.
>>> Node v21 works in same way as before, returning driver capabilities
>>> directly to the API caller. These capabilities may include new elements
>>> not part of the v20 ABI.
>>> Node v20 function maintains compatibility with v20 ABI releases
>>> by stripping out elements not supported in v20 ABI. Because
>>> rte_cryptodev_info_get is called by other API functions,
>>> rte_cryptodev_sym_capability_get function is versioned the same way.
>>>
>>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>> ---
>>> v2:
>>> - changed version numbers of symbols to 20.0.2
>>> v3:
>>> - added v2/v3 informations
>>> - changed version numbers of symbols to 21
>>> v4:
>>> - fixed clang build by movind binding default symbol
>>> - implemented mailing list comments
>>> - added abidiff tool suppression entries
>>> v5:
>>> - fixed meson build
>>>
>>> devtools/libabigail.abignore | 8 ++
>>> lib/librte_cryptodev/meson.build | 1 +
>>> lib/librte_cryptodev/rte_cryptodev.c | 147
>> ++++++++++++++++++++++++-
>>> lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
>>> lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
>>> 5 files changed, 191 insertions(+), 6 deletions(-)
>>>
>> [SNIP]
>>
>> Acked-by: Ray Kinsella <mdr@ashroe.eu>
Hi Ray,
Previously, I only ran the script for the 2 patches.
./devtools/validate-abi.sh <commit id previous to these two patches> HEAD
However when I run for v20.02 and HEAD, the list is quite big. I believe most of them are either experimental or internal PMD. But cryptodev is still there.
NOTICE: abi-compliance-checker returned 1
NOTICE: ABI may be incompatible, check reports/logs for details.
NOTICE: Incompatible list: librte_bbdev.so librte_common_iavf.so librte_common_octeontx2.so librte_cryptodev.so librte_eal.so librte_efd.so librte_eventdev.so librte_hash.so librte_ipsec.so librte_meter.so librte_pdump.so librte_pmd_crypto_scheduler.so librte_pmd_dpaa2_sec.so librte_pmd_dpaa_sec.so librte_pmd_ring.so librte_ring.so librte_vhost.so
Regards,
Akhil
> -----Original Message-----
> From: Ray Kinsella <mdr@ashroe.eu>
> Sent: Monday, May 11, 2020 1:18 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Arek Kusztal
> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: fiona.trahe@intel.com; ray.kinsella@intel.com; bruce.richardson@intel.com
> Subject: Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
> function
>
> Hi Akhil,
>
> So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
> which does not use libabigail.ignore.
>
> So you will end up with different results compared to using libabigail as follows:
>
> DPDK_ABI_REF_DIR=<some absolute path>
> DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh
>
> I did check with the "ABI Compliance Checker" (I like this tool also), however I
> got the following
>
> NOTICE: No error detected, ABI is compatible.
> INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
> INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports directory
>
> What references did you use with validate-abi.sh (I used v20.02 and HEAD).
>
> Ray K
>
> On 09/05/2020 22:11, Akhil Goyal wrote:
> > Hi Ray/Arek,
> >
> > I still see Incompatible cryptodev even after update in the abignore list.
> > I checked it with ./devtools/validate-abi.sh
> > NOTICE: ABI may be incompatible, check reports/logs for details.
> > NOTICE: Incompatible list: librte_cryptodev.so
> >
> > Did I miss something?
> >
> >
> >>
> >> On 07/05/2020 11:57, Arek Kusztal wrote:
> >>> This patch adds versioned function rte_cryptodev_info_get()
> >>> to prevent some issues with ABI policy.
> >>> Node v21 works in same way as before, returning driver capabilities
> >>> directly to the API caller. These capabilities may include new elements
> >>> not part of the v20 ABI.
> >>> Node v20 function maintains compatibility with v20 ABI releases
> >>> by stripping out elements not supported in v20 ABI. Because
> >>> rte_cryptodev_info_get is called by other API functions,
> >>> rte_cryptodev_sym_capability_get function is versioned the same way.
> >>>
> >>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >>> ---
> >>> v2:
> >>> - changed version numbers of symbols to 20.0.2
> >>> v3:
> >>> - added v2/v3 informations
> >>> - changed version numbers of symbols to 21
> >>> v4:
> >>> - fixed clang build by movind binding default symbol
> >>> - implemented mailing list comments
> >>> - added abidiff tool suppression entries
> >>> v5:
> >>> - fixed meson build
> >>>
> >>> devtools/libabigail.abignore | 8 ++
> >>> lib/librte_cryptodev/meson.build | 1 +
> >>> lib/librte_cryptodev/rte_cryptodev.c | 147
> >> ++++++++++++++++++++++++-
> >>> lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
> >>> lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
> >>> 5 files changed, 191 insertions(+), 6 deletions(-)
> >>>
> >> [SNIP]
> >>
> >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
Hi Ray,
I have applied the series on dpdk-next-crypto as per your validation of ABI.
Thomas,
Please validate this series at your end before applying to master. I am not too sure on the ABI stuff.
Regards,
Akhil
> -----Original Message-----
> From: Akhil Goyal
> Sent: Monday, May 11, 2020 1:48 PM
> To: 'Ray Kinsella' <mdr@ashroe.eu>; Arek Kusztal
> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: fiona.trahe@intel.com; ray.kinsella@intel.com; bruce.richardson@intel.com
> Subject: RE: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
> function
>
> Hi Ray,
>
> Previously, I only ran the script for the 2 patches.
>
> ./devtools/validate-abi.sh <commit id previous to these two patches> HEAD
>
> However when I run for v20.02 and HEAD, the list is quite big. I believe most of
> them are either experimental or internal PMD. But cryptodev is still there.
>
> NOTICE: abi-compliance-checker returned 1
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list: librte_bbdev.so librte_common_iavf.so
> librte_common_octeontx2.so librte_cryptodev.so librte_eal.so librte_efd.so
> librte_eventdev.so librte_hash.so librte_ipsec.so librte_meter.so
> librte_pdump.so librte_pmd_crypto_scheduler.so librte_pmd_dpaa2_sec.so
> librte_pmd_dpaa_sec.so librte_pmd_ring.so librte_ring.so librte_vhost.so
>
> Regards,
> Akhil
>
> > -----Original Message-----
> > From: Ray Kinsella <mdr@ashroe.eu>
> > Sent: Monday, May 11, 2020 1:18 PM
> > To: Akhil Goyal <akhil.goyal@nxp.com>; Arek Kusztal
> > <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> > Cc: fiona.trahe@intel.com; ray.kinsella@intel.com;
> bruce.richardson@intel.com
> > Subject: Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
> > function
> >
> > Hi Akhil,
> >
> > So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
> > which does not use libabigail.ignore.
> >
> > So you will end up with different results compared to using libabigail as follows:
> >
> > DPDK_ABI_REF_DIR=<some absolute path>
> > DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh
> >
> > I did check with the "ABI Compliance Checker" (I like this tool also), however I
> > got the following
> >
> > NOTICE: No error detected, ABI is compatible.
> > INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
> > INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports
> directory
> >
> > What references did you use with validate-abi.sh (I used v20.02 and HEAD).
> >
> > Ray K
> >
> > On 09/05/2020 22:11, Akhil Goyal wrote:
> > > Hi Ray/Arek,
> > >
> > > I still see Incompatible cryptodev even after update in the abignore list.
> > > I checked it with ./devtools/validate-abi.sh
> > > NOTICE: ABI may be incompatible, check reports/logs for details.
> > > NOTICE: Incompatible list: librte_cryptodev.so
> > >
> > > Did I miss something?
> > >
> > >
> > >>
> > >> On 07/05/2020 11:57, Arek Kusztal wrote:
> > >>> This patch adds versioned function rte_cryptodev_info_get()
> > >>> to prevent some issues with ABI policy.
> > >>> Node v21 works in same way as before, returning driver capabilities
> > >>> directly to the API caller. These capabilities may include new elements
> > >>> not part of the v20 ABI.
> > >>> Node v20 function maintains compatibility with v20 ABI releases
> > >>> by stripping out elements not supported in v20 ABI. Because
> > >>> rte_cryptodev_info_get is called by other API functions,
> > >>> rte_cryptodev_sym_capability_get function is versioned the same way.
> > >>>
> > >>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > >>> ---
> > >>> v2:
> > >>> - changed version numbers of symbols to 20.0.2
> > >>> v3:
> > >>> - added v2/v3 informations
> > >>> - changed version numbers of symbols to 21
> > >>> v4:
> > >>> - fixed clang build by movind binding default symbol
> > >>> - implemented mailing list comments
> > >>> - added abidiff tool suppression entries
> > >>> v5:
> > >>> - fixed meson build
> > >>>
> > >>> devtools/libabigail.abignore | 8 ++
> > >>> lib/librte_cryptodev/meson.build | 1 +
> > >>> lib/librte_cryptodev/rte_cryptodev.c | 147
> > >> ++++++++++++++++++++++++-
> > >>> lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
> > >>> lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
> > >>> 5 files changed, 191 insertions(+), 6 deletions(-)
> > >>>
> > >> [SNIP]
> > >>
> > >> Acked-by: Ray Kinsella <mdr@ashroe.eu>
Seems to be an issues on my side (see below).
Everything that the ABI Compliance Checker 2.3 complains about has already been reported and suppressed in libabigail.ignore.
Suggest you use libabigail going forward.
Oddly enough
Fedora 31 / ABI Compliance Checker 2.3
[root@xyz abi-check]# abi-compliance-checker -l librte_cryptodev.so -old 24cd1b529/librte_cryptodev.so.dump -new 26c1ec175/librte_cryptodev.so.dumpPreparing, please wait ...
Comparing ABIs ...
Comparing APIs ...
Creating compatibility report ...
Binary compatibility: 100%
Source compatibility: 100%
Total binary compatibility problems: 0, warnings: 0
Total source compatibility problems: 0, warnings: 0
Report: compat_reports/librte_cryptodev.so/24cd1b529_to_26c1ec175/compat_report.html
Ubuntu 18.04/ ABI Compliance Checker 2.2
root@abc:/build/dpdk-next-crypto/abi-check# abi-compliance-checker -l librte_cryptodev.so -old 6ef23d92d/librte_cryptodev.so.dump -new 6488cc1cf/librte_cryptodev.so.dump
Preparing, please wait ...
Comparing ABIs ...
Comparing APIs ...
Creating compatibility report ...
Binary compatibility: 99.4%
Source compatibility: 100%
Total binary compatibility problems: 1, warnings: 1
Total source compatibility problems: 0, warnings: 0
Report: compat_reports/librte_cryptodev.so/6ef23d92d_to_6488cc1cf/compat_report.html
Ray K
On 11/05/2020 09:18, Akhil Goyal wrote:
> Hi Ray,
>
> Previously, I only ran the script for the 2 patches.
>
> ./devtools/validate-abi.sh <commit id previous to these two patches> HEAD
>
> However when I run for v20.02 and HEAD, the list is quite big. I believe most of them are either experimental or internal PMD. But cryptodev is still there.
>
> NOTICE: abi-compliance-checker returned 1
> NOTICE: ABI may be incompatible, check reports/logs for details.
> NOTICE: Incompatible list: librte_bbdev.so librte_common_iavf.so librte_common_octeontx2.so librte_cryptodev.so librte_eal.so librte_efd.so librte_eventdev.so librte_hash.so librte_ipsec.so librte_meter.so librte_pdump.so librte_pmd_crypto_scheduler.so librte_pmd_dpaa2_sec.so librte_pmd_dpaa_sec.so librte_pmd_ring.so librte_ring.so librte_vhost.so
>
> Regards,
> Akhil
>
>> -----Original Message-----
>> From: Ray Kinsella <mdr@ashroe.eu>
>> Sent: Monday, May 11, 2020 1:18 PM
>> To: Akhil Goyal <akhil.goyal@nxp.com>; Arek Kusztal
>> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
>> Cc: fiona.trahe@intel.com; ray.kinsella@intel.com; bruce.richardson@intel.com
>> Subject: Re: [dpdk-dev] [PATCH v5 2/2] cryptodev: version cryptodev info get
>> function
>>
>> Hi Akhil,
>>
>> So 1st thing is that this that validate-abi uses "ABI Compliance Checker",
>> which does not use libabigail.ignore.
>>
>> So you will end up with different results compared to using libabigail as follows:
>>
>> DPDK_ABI_REF_DIR=<some absolute path>
>> DPDK_ABI_REF_VERSION=v20.02 ./devtools/test-meson-builds.sh
>>
>> I did check with the "ABI Compliance Checker" (I like this tool also), however I
>> got the following
>>
>> NOTICE: No error detected, ABI is compatible.
>> INFO: Logs are in /root/src/dpdk/abi-check/abi-check.log
>> INFO: HTML reports are in /root/src/dpdk/abi-check/compat_reports directory
>>
>> What references did you use with validate-abi.sh (I used v20.02 and HEAD).
>>
>> Ray K
>>
>> On 09/05/2020 22:11, Akhil Goyal wrote:
>>> Hi Ray/Arek,
>>>
>>> I still see Incompatible cryptodev even after update in the abignore list.
>>> I checked it with ./devtools/validate-abi.sh
>>> NOTICE: ABI may be incompatible, check reports/logs for details.
>>> NOTICE: Incompatible list: librte_cryptodev.so
>>>
>>> Did I miss something?
>>>
>>>
>>>>
>>>> On 07/05/2020 11:57, Arek Kusztal wrote:
>>>>> This patch adds versioned function rte_cryptodev_info_get()
>>>>> to prevent some issues with ABI policy.
>>>>> Node v21 works in same way as before, returning driver capabilities
>>>>> directly to the API caller. These capabilities may include new elements
>>>>> not part of the v20 ABI.
>>>>> Node v20 function maintains compatibility with v20 ABI releases
>>>>> by stripping out elements not supported in v20 ABI. Because
>>>>> rte_cryptodev_info_get is called by other API functions,
>>>>> rte_cryptodev_sym_capability_get function is versioned the same way.
>>>>>
>>>>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>>>> ---
>>>>> v2:
>>>>> - changed version numbers of symbols to 20.0.2
>>>>> v3:
>>>>> - added v2/v3 informations
>>>>> - changed version numbers of symbols to 21
>>>>> v4:
>>>>> - fixed clang build by movind binding default symbol
>>>>> - implemented mailing list comments
>>>>> - added abidiff tool suppression entries
>>>>> v5:
>>>>> - fixed meson build
>>>>>
>>>>> devtools/libabigail.abignore | 8 ++
>>>>> lib/librte_cryptodev/meson.build | 1 +
>>>>> lib/librte_cryptodev/rte_cryptodev.c | 147
>>>> ++++++++++++++++++++++++-
>>>>> lib/librte_cryptodev/rte_cryptodev.h | 34 +++++-
>>>>> lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++
>>>>> 5 files changed, 191 insertions(+), 6 deletions(-)
>>>>>
>>>> [SNIP]
>>>>
>>>> Acked-by: Ray Kinsella <mdr@ashroe.eu>
@@ -24,3 +24,11 @@
type_kind = enum
name = rte_eth_event_type
changed_enumerators = RTE_ETH_EVENT_MAX
+; Ignore Cryptodev AEAD xform enum and AEAD xform strings change
+; due to addition of Chacha20-Poly1305
+[suppress_type]
+ type_kind = enum
+ name = rte_crypto_aead_algorithm
+ changed_enumerators = RTE_CRYPTO_AEAD_LIST_END
+[suppress_variable]
+ name = rte_crypto_aead_algorithm_strings
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017-2019 Intel Corporation
+use_function_versioning = true
sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c', 'cryptodev_trace_points.c')
headers = files('rte_cryptodev.h',
'rte_cryptodev_pmd.h',
@@ -36,6 +36,8 @@
#include <rte_errno.h>
#include <rte_spinlock.h>
#include <rte_string_fns.h>
+#include <rte_compat.h>
+#include <rte_function_versioning.h>
#include "rte_crypto.h"
#include "rte_cryptodev.h"
@@ -57,6 +59,14 @@ static struct rte_cryptodev_global cryptodev_globals = {
/* spinlock for crypto device callbacks */
static rte_spinlock_t rte_cryptodev_cb_lock = RTE_SPINLOCK_INITIALIZER;
+static const struct rte_cryptodev_capabilities
+ cryptodev_undefined_capabilities[] = {
+ RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
+};
+
+static struct rte_cryptodev_capabilities
+ *capability_copy[RTE_CRYPTO_MAX_DEVS];
+static uint8_t is_capability_checked[RTE_CRYPTO_MAX_DEVS];
/**
* The user application callback description.
@@ -281,15 +291,15 @@ rte_crypto_auth_operation_strings[] = {
[RTE_CRYPTO_AUTH_OP_GENERATE] = "generate"
};
-const struct rte_cryptodev_symmetric_capability *
-rte_cryptodev_sym_capability_get(uint8_t dev_id,
+const struct rte_cryptodev_symmetric_capability __vsym *
+rte_cryptodev_sym_capability_get_v20(uint8_t dev_id,
const struct rte_cryptodev_sym_capability_idx *idx)
{
const struct rte_cryptodev_capabilities *capability;
struct rte_cryptodev_info dev_info;
int i = 0;
- rte_cryptodev_info_get(dev_id, &dev_info);
+ rte_cryptodev_info_get_v20(dev_id, &dev_info);
while ((capability = &dev_info.capabilities[i++])->op !=
RTE_CRYPTO_OP_TYPE_UNDEFINED) {
@@ -313,8 +323,47 @@ rte_cryptodev_sym_capability_get(uint8_t dev_id,
}
return NULL;
+}
+VERSION_SYMBOL(rte_cryptodev_sym_capability_get, _v20, 20.0);
+
+const struct rte_cryptodev_symmetric_capability __vsym *
+rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
+ const struct rte_cryptodev_sym_capability_idx *idx)
+{
+ const struct rte_cryptodev_capabilities *capability;
+ struct rte_cryptodev_info dev_info;
+ int i = 0;
+
+ rte_cryptodev_info_get(dev_id, &dev_info);
+
+ while ((capability = &dev_info.capabilities[i++])->op !=
+ RTE_CRYPTO_OP_TYPE_UNDEFINED) {
+ if (capability->op != RTE_CRYPTO_OP_TYPE_SYMMETRIC)
+ continue;
+ if (capability->sym.xform_type != idx->type)
+ continue;
+
+ if (idx->type == RTE_CRYPTO_SYM_XFORM_AUTH &&
+ capability->sym.auth.algo == idx->algo.auth)
+ return &capability->sym;
+
+ if (idx->type == RTE_CRYPTO_SYM_XFORM_CIPHER &&
+ capability->sym.cipher.algo == idx->algo.cipher)
+ return &capability->sym;
+
+ if (idx->type == RTE_CRYPTO_SYM_XFORM_AEAD &&
+ capability->sym.aead.algo == idx->algo.aead)
+ return &capability->sym;
+ }
+
+ return NULL;
}
+MAP_STATIC_SYMBOL(const struct rte_cryptodev_symmetric_capability *
+ rte_cryptodev_sym_capability_get(uint8_t dev_id,
+ const struct rte_cryptodev_sym_capability_idx *idx),
+ rte_cryptodev_sym_capability_get_v21);
+BIND_DEFAULT_SYMBOL(rte_cryptodev_sym_capability_get, _v21, 21);
static int
param_range_check(uint16_t size, const struct rte_crypto_param_range *range)
@@ -1016,6 +1065,12 @@ rte_cryptodev_close(uint8_t dev_id)
retval = (*dev->dev_ops->dev_close)(dev);
rte_cryptodev_trace_close(dev_id, retval);
+ if (capability_copy[dev_id]) {
+ free(capability_copy[dev_id]);
+ capability_copy[dev_id] = NULL;
+ }
+ is_capability_checked[dev_id] = 0;
+
if (retval < 0)
return retval;
@@ -1129,9 +1184,61 @@ rte_cryptodev_stats_reset(uint8_t dev_id)
(*dev->dev_ops->stats_reset)(dev);
}
+static void
+get_v20_capabilities(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
+{
+ const struct rte_cryptodev_capabilities *capability;
+ uint8_t found_invalid_capa = 0;
+ uint8_t counter = 0;
+
+ for (capability = dev_info->capabilities;
+ capability->op != RTE_CRYPTO_OP_TYPE_UNDEFINED;
+ ++capability, ++counter) {
+ if (capability->op == RTE_CRYPTO_OP_TYPE_SYMMETRIC &&
+ capability->sym.xform_type ==
+ RTE_CRYPTO_SYM_XFORM_AEAD
+ && capability->sym.aead.algo >=
+ RTE_CRYPTO_AEAD_CHACHA20_POLY1305) {
+ found_invalid_capa = 1;
+ counter--;
+ }
+ }
+ is_capability_checked[dev_id] = 1;
+ if (!found_invalid_capa)
+ return;
+ capability_copy[dev_id] = malloc(counter *
+ sizeof(struct rte_cryptodev_capabilities));
+ if (capability_copy[dev_id] == NULL) {
+ /*
+ * error case - no memory to store the trimmed
+ * list, so have to return an empty list
+ */
+ dev_info->capabilities =
+ cryptodev_undefined_capabilities;
+ is_capability_checked[dev_id] = 0;
+ } else {
+ counter = 0;
+ for (capability = dev_info->capabilities;
+ capability->op !=
+ RTE_CRYPTO_OP_TYPE_UNDEFINED;
+ capability++) {
+ if (!(capability->op ==
+ RTE_CRYPTO_OP_TYPE_SYMMETRIC
+ && capability->sym.xform_type ==
+ RTE_CRYPTO_SYM_XFORM_AEAD
+ && capability->sym.aead.algo >=
+ RTE_CRYPTO_AEAD_CHACHA20_POLY1305)) {
+ capability_copy[dev_id][counter++] =
+ *capability;
+ }
+ }
+ dev_info->capabilities =
+ capability_copy[dev_id];
+ }
+}
-void
-rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
+void __vsym
+rte_cryptodev_info_get_v20(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
{
struct rte_cryptodev *dev;
@@ -1147,10 +1254,40 @@ rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
+ if (capability_copy[dev_id] == NULL) {
+ if (!is_capability_checked[dev_id])
+ get_v20_capabilities(dev_id, dev_info);
+ } else
+ dev_info->capabilities = capability_copy[dev_id];
+
dev_info->driver_name = dev->device->driver->name;
dev_info->device = dev->device;
}
+VERSION_SYMBOL(rte_cryptodev_info_get, _v20, 20.0);
+void __vsym
+rte_cryptodev_info_get_v21(uint8_t dev_id, struct rte_cryptodev_info *dev_info)
+{
+ struct rte_cryptodev *dev;
+
+ if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
+ CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
+ return;
+ }
+
+ dev = &rte_crypto_devices[dev_id];
+
+ memset(dev_info, 0, sizeof(struct rte_cryptodev_info));
+
+ RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
+ (*dev->dev_ops->dev_infos_get)(dev, dev_info);
+
+ dev_info->driver_name = dev->device->driver->name;
+ dev_info->device = dev->device;
+}
+MAP_STATIC_SYMBOL(void rte_cryptodev_info_get(uint8_t dev_id,
+ struct rte_cryptodev_info *dev_info), rte_cryptodev_info_get_v21);
+BIND_DEFAULT_SYMBOL(rte_cryptodev_info_get, _v21, 21);
int
rte_cryptodev_callback_register(uint8_t dev_id,
@@ -219,6 +219,14 @@ struct rte_cryptodev_asym_capability_idx {
* - Return NULL if the capability not exist.
*/
const struct rte_cryptodev_symmetric_capability *
+rte_cryptodev_sym_capability_get_v20(uint8_t dev_id,
+ const struct rte_cryptodev_sym_capability_idx *idx);
+
+const struct rte_cryptodev_symmetric_capability *
+rte_cryptodev_sym_capability_get_v21(uint8_t dev_id,
+ const struct rte_cryptodev_sym_capability_idx *idx);
+
+const struct rte_cryptodev_symmetric_capability *
rte_cryptodev_sym_capability_get(uint8_t dev_id,
const struct rte_cryptodev_sym_capability_idx *idx);
@@ -762,9 +770,33 @@ rte_cryptodev_stats_reset(uint8_t dev_id);
* the last valid element has it's op field set to
* RTE_CRYPTO_OP_TYPE_UNDEFINED.
*/
-extern void
+
+void
rte_cryptodev_info_get(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
+/* An extra element RTE_CRYPTO_AEAD_CHACHA20_POLY1305 is added
+ * to enum rte_crypto_aead_algorithm, also changing the value of
+ * RTE_CRYPTO_AEAD_LIST_END. To maintain ABI compatibility with applications
+ * which linked against earlier versions, preventing them, for example, from
+ * picking up the new value and using it to index into an array sized too small
+ * for it, it is necessary to have two versions of rte_cryptodev_info_get()
+ * The latest version just returns directly the capabilities retrieved from
+ * the device. The compatible version inspects the capabilities retrieved
+ * from the device, but only returns them directly if the new value
+ * is not included. If the new value is included, it allocates space
+ * for a copy of the device capabilities, trims the new value from this
+ * and returns this copy. It only needs to do this once per device.
+ * For the corner case of a corner case when the alloc may fail,
+ * an empty capability list is returned, as there is no mechanism to return
+ * an error and adding such a mechanism would itself be an ABI breakage.
+ * The compatible version can be removed after the next major ABI release.
+ */
+
+void
+rte_cryptodev_info_get_v20(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
+
+void
+rte_cryptodev_info_get_v21(uint8_t dev_id, struct rte_cryptodev_info *dev_info);
/**
* Register a callback function for specific device id.
@@ -58,6 +58,13 @@ DPDK_20.0 {
local: *;
};
+DPDK_21 {
+ global:
+ rte_cryptodev_info_get;
+ rte_cryptodev_sym_capability_get;
+} DPDK_20.0;
+
+
EXPERIMENTAL {
global: