diff mbox series

[v2,01/33] config: add Cavium OcteonTX crypto PMD skeleton

Message ID 1536033560-21541-2-git-send-email-ajoseph@caviumnetworks.com (mailing list archive)
State Superseded, archived
Delegated to: akhil goyal
Headers
Series Adding Cavium's OcteonTX crypto PMD |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Anoob Joseph Sept. 4, 2018, 3:58 a.m. UTC 
  From: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>

This adds Makefile, meson.build and config file options.
Also adds the version map files and maintainers
file to claim responsibility.

Signed-off-by: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>
Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
Signed-off-by: Murthy NSSR <nidadavolu.murthy@caviumnetworks.com>
Signed-off-by: Nithin Dabilpuram <nithin.dabilpuram@caviumnetworks.com>
Signed-off-by: Ragothaman Jayaraman <rjayaraman@caviumnetworks.com>
Signed-off-by: Srisivasubramanian S <ssrinivasan@caviumnetworks.com>
Signed-off-by: Tejasree Kondoj <kondoj.tejasree@caviumnetworks.com>
---
 MAINTAINERS                                        |  7 ++++
 config/common_base                                 |  5 +++
 drivers/crypto/Makefile                            |  1 +
 drivers/crypto/meson.build                         |  2 +-
 drivers/crypto/octeontx/Makefile                   | 37 ++++++++++++++++++++++
 drivers/crypto/octeontx/meson.build                | 12 +++++++
 .../octeontx/rte_pmd_octeontx_crypto_version.map   |  4 +++
 mk/rte.app.mk                                      |  1 +
 8 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/octeontx/Makefile
 create mode 100644 drivers/crypto/octeontx/meson.build
 create mode 100644 drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map

Comments

Akhil Goyal Sept. 14, 2018, 12:11 p.m. UTC | #1 
Hi Anoob,

On 9/4/2018 9:28 AM, Anoob Joseph wrote:

> From: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>
>
> This adds Makefile, meson.build and config file options.
> Also adds the version map files and maintainers
> file to claim responsibility.
>
> Signed-off-by: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>
> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> Signed-off-by: Murthy NSSR <nidadavolu.murthy@caviumnetworks.com>
> Signed-off-by: Nithin Dabilpuram <nithin.dabilpuram@caviumnetworks.com>
> Signed-off-by: Ragothaman Jayaraman <rjayaraman@caviumnetworks.com>
> Signed-off-by: Srisivasubramanian S <ssrinivasan@caviumnetworks.com>
> Signed-off-by: Tejasree Kondoj <kondoj.tejasree@caviumnetworks.com>
> ---
>   MAINTAINERS                                        |  7 ++++
>   config/common_base                                 |  5 +++
>   drivers/crypto/Makefile                            |  1 +
>   drivers/crypto/meson.build                         |  2 +-
>   drivers/crypto/octeontx/Makefile                   | 37 ++++++++++++++++++++++
>   drivers/crypto/octeontx/meson.build                | 12 +++++++
>   .../octeontx/rte_pmd_octeontx_crypto_version.map   |  4 +++
>   mk/rte.app.mk                                      |  1 +
>   8 files changed, 68 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/crypto/octeontx/Makefile
>   create mode 100644 drivers/crypto/octeontx/meson.build
>   create mode 100644 drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9fd258f..09548fa 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -771,6 +771,13 @@ F: drivers/crypto/armv8/
>   F: doc/guides/cryptodevs/armv8.rst
>   F: doc/guides/cryptodevs/features/armv8.ini
>   
> +Cavium OcteonTX
> +M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
> +F: drivers/common/cpt/
> +F: drivers/crypto/octeontx/
> +F: doc/guides/cryptodevs/octeontx.rst
> +F: doc/guides/cryptodevs/features/octeontx.ini

octeontx.rst and octeontx.ini does not exist. Please update MAINTAINERS in
the patch which is adding this file.

> +
>   Crypto Scheduler
>   M: Fan Zhang <roy.fan.zhang@intel.com>
>   F: drivers/crypto/scheduler/
> diff --git a/config/common_base b/config/common_base
> index 4bcbaf9..4c6a951 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -635,6 +635,11 @@ CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV=n
>   CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=n
>   
>   #
> +# Compile PMD for Cavium OcteonTX crypto device
> +#
> +CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO=y
> +
> +#
>   # Compile raw device support
>   # EXPERIMENTAL: API may change without prior notice
>   #
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index c480cbd..c083e64 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -7,6 +7,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_GCM) += aesni_gcm
>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += aesni_mb
>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO) += armv8
>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_CCP) += ccp
> +DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += octeontx
>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPENSSL) += openssl
>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += scheduler
>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_SNOW3G) += snow3g
> diff --git a/drivers/crypto/meson.build b/drivers/crypto/meson.build
> index d64ca41..2187870 100644
> --- a/drivers/crypto/meson.build
> +++ b/drivers/crypto/meson.build
> @@ -2,7 +2,7 @@
>   # Copyright(c) 2017 Intel Corporation
>   
>   drivers = ['ccp', 'dpaa_sec', 'dpaa2_sec', 'mvsam',
> -	'null', 'openssl', 'qat', 'virtio']
> +	'null', 'octeontx', 'openssl', 'qat', 'virtio']
>   
>   std_deps = ['cryptodev'] # cryptodev pulls in all other needed deps
>   config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
> diff --git a/drivers/crypto/octeontx/Makefile b/drivers/crypto/octeontx/Makefile
> new file mode 100644
> index 0000000..65bd02f
> --- /dev/null
> +++ b/drivers/crypto/octeontx/Makefile
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2018 Cavium, Inc
> +#
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +# library name
> +LIB = librte_pmd_octeontx_crypto.a
> +
> +# library version
> +LIBABIVER := 1
> +
> +# build flags
> +CFLAGS += $(WERROR_FLAGS)
> +
> +LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
> +LDLIBS += -lrte_cryptodev
> +LDLIBS += -lrte_pci -lrte_bus_pci
> +
> +VPATH += $(RTE_SDK)/drivers/crypto/octeontx
> +
> +CFLAGS += -O3 -DCPT_MODEL=CRYPTO_OCTEONTX
> +
> +# export include files
> +SYMLINK-y-include +=
> +
> +# versioning export map
> +EXPORT_MAP := rte_pmd_octeontx_crypto_version.map
> +
> +# library dependencies
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_eal
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_cryptodev
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_mempool
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_mbuf
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_malloc
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/drivers/crypto/octeontx/meson.build b/drivers/crypto/octeontx/meson.build
> new file mode 100644
> index 0000000..261bb77
> --- /dev/null
> +++ b/drivers/crypto/octeontx/meson.build
> @@ -0,0 +1,12 @@
> +# SPDX-License-Identifier: BSD-3-Clause
> +# Copyright(c) 2018 Cavium, Inc
> +if host_machine.system() != 'linux'
> +	build = false
> +endif
> +
> +deps += ['bus_pci']
> +name = 'octeontx_crypto'
> +
> +sources = files()
> +
> +cflags += '-DCPT_MODEL=CRYPTO_OCTEONTX'
> diff --git a/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
> new file mode 100644
> index 0000000..521e51f
> --- /dev/null
> +++ b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
> @@ -0,0 +1,4 @@
> +DPDK_18.11 {
> +
> +	local: *;
> +};
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> index de33883..b530337 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -211,6 +211,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ZUC)         += -L$(LIBSSO_ZUC_PATH)/build -lsso
>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO)    += -lrte_pmd_armv8
>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO)    += -L$(ARMV8_CRYPTO_LIB_PATH) -larmv8_crypto
>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_MVSAM_CRYPTO) += -L$(LIBMUSDK_PATH)/lib -lrte_pmd_mvsam_crypto -lmusdk
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += -lrte_pmd_octeontx_crypto
>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += -lrte_pmd_crypto_scheduler
>   ifeq ($(CONFIG_RTE_EAL_VFIO)$(CONFIG_RTE_LIBRTE_FSLMC_BUS),yy)
>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC)   += -lrte_pmd_dpaa2_sec
>
I think it would be better to squash the makefile related changes in the 3/33 patch as the code

is actually added in that and here the code is not getting compiled here.

-Akhil
Anoob Joseph Sept. 17, 2018, 4:22 a.m. UTC | #2 
Hi Akhil,

Please see inline.

Thanks,
Anoob

On 14-09-2018 17:41, Akhil Goyal wrote:
> External Email
>
> Hi Anoob,
>
> On 9/4/2018 9:28 AM, Anoob Joseph wrote:
>
>> From: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>
>>
>> This adds Makefile, meson.build and config file options.
>> Also adds the version map files and maintainers
>> file to claim responsibility.
>>
>> Signed-off-by: Ankur Dwivedi <ankur.dwivedi@caviumnetworks.com>
>> Signed-off-by: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> Signed-off-by: Murthy NSSR <nidadavolu.murthy@caviumnetworks.com>
>> Signed-off-by: Nithin Dabilpuram <nithin.dabilpuram@caviumnetworks.com>
>> Signed-off-by: Ragothaman Jayaraman <rjayaraman@caviumnetworks.com>
>> Signed-off-by: Srisivasubramanian S <ssrinivasan@caviumnetworks.com>
>> Signed-off-by: Tejasree Kondoj <kondoj.tejasree@caviumnetworks.com>
>> ---
>>   MAINTAINERS                                        |  7 ++++
>>   config/common_base                                 |  5 +++
>>   drivers/crypto/Makefile                            |  1 +
>>   drivers/crypto/meson.build                         |  2 +-
>>   drivers/crypto/octeontx/Makefile                   | 37 
>> ++++++++++++++++++++++
>>   drivers/crypto/octeontx/meson.build                | 12 +++++++
>>   .../octeontx/rte_pmd_octeontx_crypto_version.map   |  4 +++
>>   mk/rte.app.mk                                      |  1 +
>>   8 files changed, 68 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/crypto/octeontx/Makefile
>>   create mode 100644 drivers/crypto/octeontx/meson.build
>>   create mode 100644 
>> drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9fd258f..09548fa 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -771,6 +771,13 @@ F: drivers/crypto/armv8/
>>   F: doc/guides/cryptodevs/armv8.rst
>>   F: doc/guides/cryptodevs/features/armv8.ini
>>
>> +Cavium OcteonTX
>> +M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
>> +F: drivers/common/cpt/
>> +F: drivers/crypto/octeontx/
>> +F: doc/guides/cryptodevs/octeontx.rst
>> +F: doc/guides/cryptodevs/features/octeontx.ini
>
> octeontx.rst and octeontx.ini does not exist. Please update 
> MAINTAINERS in
> the patch which is adding this file.
Will do so.
>
>> +
>>   Crypto Scheduler
>>   M: Fan Zhang <roy.fan.zhang@intel.com>
>>   F: drivers/crypto/scheduler/
>> diff --git a/config/common_base b/config/common_base
>> index 4bcbaf9..4c6a951 100644
>> --- a/config/common_base
>> +++ b/config/common_base
>> @@ -635,6 +635,11 @@ CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV=n
>>   CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=n
>>
>>   #
>> +# Compile PMD for Cavium OcteonTX crypto device
>> +#
>> +CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO=y
>> +
>> +#
>>   # Compile raw device support
>>   # EXPERIMENTAL: API may change without prior notice
>>   #
>> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>> index c480cbd..c083e64 100644
>> --- a/drivers/crypto/Makefile
>> +++ b/drivers/crypto/Makefile
>> @@ -7,6 +7,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_GCM) += aesni_gcm
>>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += aesni_mb
>>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO) += armv8
>>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_CCP) += ccp
>> +DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += octeontx
>>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPENSSL) += openssl
>>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += scheduler
>>   DIRS-$(CONFIG_RTE_LIBRTE_PMD_SNOW3G) += snow3g
>> diff --git a/drivers/crypto/meson.build b/drivers/crypto/meson.build
>> index d64ca41..2187870 100644
>> --- a/drivers/crypto/meson.build
>> +++ b/drivers/crypto/meson.build
>> @@ -2,7 +2,7 @@
>>   # Copyright(c) 2017 Intel Corporation
>>
>>   drivers = ['ccp', 'dpaa_sec', 'dpaa2_sec', 'mvsam',
>> -     'null', 'openssl', 'qat', 'virtio']
>> +     'null', 'octeontx', 'openssl', 'qat', 'virtio']
>>
>>   std_deps = ['cryptodev'] # cryptodev pulls in all other needed deps
>>   config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
>> diff --git a/drivers/crypto/octeontx/Makefile 
>> b/drivers/crypto/octeontx/Makefile
>> new file mode 100644
>> index 0000000..65bd02f
>> --- /dev/null
>> +++ b/drivers/crypto/octeontx/Makefile
>> @@ -0,0 +1,37 @@
>> +# SPDX-License-Identifier: BSD-3-Clause
>> +# Copyright(c) 2018 Cavium, Inc
>> +#
>> +
>> +include $(RTE_SDK)/mk/rte.vars.mk
>> +
>> +# library name
>> +LIB = librte_pmd_octeontx_crypto.a
>> +
>> +# library version
>> +LIBABIVER := 1
>> +
>> +# build flags
>> +CFLAGS += $(WERROR_FLAGS)
>> +
>> +LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
>> +LDLIBS += -lrte_cryptodev
>> +LDLIBS += -lrte_pci -lrte_bus_pci
>> +
>> +VPATH += $(RTE_SDK)/drivers/crypto/octeontx
>> +
>> +CFLAGS += -O3 -DCPT_MODEL=CRYPTO_OCTEONTX
>> +
>> +# export include files
>> +SYMLINK-y-include +=
>> +
>> +# versioning export map
>> +EXPORT_MAP := rte_pmd_octeontx_crypto_version.map
>> +
>> +# library dependencies
>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_eal
>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += 
>> lib/librte_cryptodev
>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_mempool
>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_mbuf
>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_malloc
>> +
>> +include $(RTE_SDK)/mk/rte.lib.mk
>> diff --git a/drivers/crypto/octeontx/meson.build 
>> b/drivers/crypto/octeontx/meson.build
>> new file mode 100644
>> index 0000000..261bb77
>> --- /dev/null
>> +++ b/drivers/crypto/octeontx/meson.build
>> @@ -0,0 +1,12 @@
>> +# SPDX-License-Identifier: BSD-3-Clause
>> +# Copyright(c) 2018 Cavium, Inc
>> +if host_machine.system() != 'linux'
>> +     build = false
>> +endif
>> +
>> +deps += ['bus_pci']
>> +name = 'octeontx_crypto'
>> +
>> +sources = files()
>> +
>> +cflags += '-DCPT_MODEL=CRYPTO_OCTEONTX'
>> diff --git 
>> a/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map 
>> b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
>> new file mode 100644
>> index 0000000..521e51f
>> --- /dev/null
>> +++ b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
>> @@ -0,0 +1,4 @@
>> +DPDK_18.11 {
>> +
>> +     local: *;
>> +};
>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
>> index de33883..b530337 100644
>> --- a/mk/rte.app.mk
>> +++ b/mk/rte.app.mk
>> @@ -211,6 +211,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ZUC) += 
>> -L$(LIBSSO_ZUC_PATH)/build -lsso
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO)    += -lrte_pmd_armv8
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO)    += 
>> -L$(ARMV8_CRYPTO_LIB_PATH) -larmv8_crypto
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_MVSAM_CRYPTO) += 
>> -L$(LIBMUSDK_PATH)/lib -lrte_pmd_mvsam_crypto -lmusdk
>> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += 
>> -lrte_pmd_octeontx_crypto
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += 
>> -lrte_pmd_crypto_scheduler
>>   ifeq ($(CONFIG_RTE_EAL_VFIO)$(CONFIG_RTE_LIBRTE_FSLMC_BUS),yy)
>>   _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC)   += -lrte_pmd_dpaa2_sec
>>
> I think it would be better to squash the makefile related changes in 
> the 3/33 patch as the code
>
> is actually added in that and here the code is not getting compiled here.
So the changes in the following files has to be moved to patch 3/33?
   drivers/crypto/Makefile
   drivers/crypto/meson.build
   drivers/crypto/octeontx/Makefile
   drivers/crypto/octeontx/meson.build
   mk/rte.app.mk

I think this patch will just have MAINTAINER edit (even that might be 
required to be moved to 3/33?) & changes to config/common_base, after 
that. Is that fine?
>
> -Akhil
>
Akhil Goyal Sept. 17, 2018, 10:37 a.m. UTC | #3 
>>>
>> I think it would be better to squash the makefile related changes in 
>> the 3/33 patch as the code
>>
>> is actually added in that and here the code is not getting compiled 
>> here.
> So the changes in the following files has to be moved to patch 3/33?
>   drivers/crypto/Makefile
>   drivers/crypto/meson.build
>   drivers/crypto/octeontx/Makefile
>   drivers/crypto/octeontx/meson.build
>   mk/rte.app.mk
>
> I think this patch will just have MAINTAINER edit (even that might be 
> required to be moved to 3/33?) & changes to config/common_base, after 
> that. Is that fine?
In my opinion, you do not need this patch as separate one. 
config/common_base can also be added in the 3/33.
>>
>> -Akhil
>>
>
Anoob Joseph Sept. 17, 2018, 11:42 a.m. UTC | #4 
Hi Akhil,

On 17-09-2018 16:07, Akhil Goyal wrote:
> External Email
>
>>>>
>>> I think it would be better to squash the makefile related changes in
>>> the 3/33 patch as the code
>>>
>>> is actually added in that and here the code is not getting compiled
>>> here.
>> So the changes in the following files has to be moved to patch 3/33?
>>   drivers/crypto/Makefile
>>   drivers/crypto/meson.build
>>   drivers/crypto/octeontx/Makefile
>>   drivers/crypto/octeontx/meson.build
>>   mk/rte.app.mk
>>
>> I think this patch will just have MAINTAINER edit (even that might be
>> required to be moved to 3/33?) & changes to config/common_base, after
>> that. Is that fine?
> In my opinion, you do not need this patch as separate one.
> config/common_base can also be added in the 3/33.
In that case 02/33 patch would become the first patch right? The same 
problem would be there too, I guess. The macros added in that patch gets 
used only in 03/33 patch. Is that fine?

The first patch would be a shell patch for most PMD additions. That's 
the reason we started this way. If you want it changed, will do so. 
Please do let me know what will be the right approach.

Anoob
Akhil Goyal Sept. 17, 2018, 12:20 p.m. UTC | #5 
On 9/17/2018 5:12 PM, Joseph, Anoob wrote:

> Hi Akhil,
> On 17-09-2018 16:07, Akhil Goyal wrote:
>> External Email
>>>> I think it would be better to squash the makefile related changes in
>>>> the 3/33 patch as the code
>>>> is actually added in that and here the code is not getting compiled
>>>> here.
>>> So the changes in the following files has to be moved to patch 3/33?
>>>    drivers/crypto/Makefile
>>>    drivers/crypto/meson.build
>>>    drivers/crypto/octeontx/Makefile
>>>    drivers/crypto/octeontx/meson.build
>>>    mk/rte.app.mk
>>> I think this patch will just have MAINTAINER edit (even that might be
>>> required to be moved to 3/33?) & changes to config/common_base, after
>>> that. Is that fine?
>> In my opinion, you do not need this patch as separate one.
>> config/common_base can also be added in the 3/33.
> In that case 02/33 patch would become the first patch right? The same
> problem would be there too, I guess. The macros added in that patch gets
> used only in 03/33 patch. Is that fine?

I think that would be fine. Better to have a 03/33 patch before 02/33 if it doesn't have dependencies.

> The first patch would be a shell patch for most PMD additions. That's
> the reason we started this way. If you want it changed, will do so.
> Please do let me know what will be the right approach.

For the makefiles, you would be compiling the empty files which does not have any code. That does not make any sense to me.

Normally, when we submit a new PMD, we add the basic PMD probe/remove in the first patch and add it into build system. Maintainers is also updated for the new PMD.

Further ops are added later in the patchset.

Hardware specific header files/ functions are added before they are used in the driver in a single/multiple logical patches.

In the end, documentation is added along with release note and MAINTAINERS update for documentation files.

- Akhil
Anoob Joseph Sept. 17, 2018, 2:13 p.m. UTC | #6 
Hi Akhil,


On 17-09-2018 17:50, Akhil Goyal wrote:
> External Email
>
> On 9/17/2018 5:12 PM, Joseph, Anoob wrote:
>
>> Hi Akhil,
>> On 17-09-2018 16:07, Akhil Goyal wrote:
>>> External Email
>>>>> I think it would be better to squash the makefile related changes in
>>>>> the 3/33 patch as the code
>>>>> is actually added in that and here the code is not getting compiled
>>>>> here.
>>>> So the changes in the following files has to be moved to patch 3/33?
>>>>    drivers/crypto/Makefile
>>>>    drivers/crypto/meson.build
>>>>    drivers/crypto/octeontx/Makefile
>>>>    drivers/crypto/octeontx/meson.build
>>>>    mk/rte.app.mk
>>>> I think this patch will just have MAINTAINER edit (even that might be
>>>> required to be moved to 3/33?) & changes to config/common_base, after
>>>> that. Is that fine?
>>> In my opinion, you do not need this patch as separate one.
>>> config/common_base can also be added in the 3/33.
>> In that case 02/33 patch would become the first patch right? The same
>> problem would be there too, I guess. The macros added in that patch gets
>> used only in 03/33 patch. Is that fine?
>
> I think that would be fine. Better to have a 03/33 patch before 02/33 
> if it doesn't have dependencies.
03/33 patch is dependent on 02/33 patch. Shall I proceed with merging 
01/33 to 03/33 and make 02/33 the first patch?
>
>> The first patch would be a shell patch for most PMD additions. That's
>> the reason we started this way. If you want it changed, will do so.
>> Please do let me know what will be the right approach.
>
> For the makefiles, you would be compiling the empty files which does 
> not have any code. That does not make any sense to me.
With 01/33 there won't be any files compiled. We are just adding the 
library (which would be empty)
>
> Normally, when we submit a new PMD, we add the basic PMD probe/remove 
> in the first patch and add it into build system. Maintainers is also 
> updated for the new PMD.
>
> Further ops are added later in the patchset.
>
> Hardware specific header files/ functions are added before they are 
> used in the driver in a single/multiple logical patches.
>
> In the end, documentation is added along with release note and 
> MAINTAINERS update for documentation files.
I shall proceed with merging 01/33 to 03/33, if you can confirm making 
02/33 the first patch is fine. Or please do let me know if you have any 
other suggestions.

Anoob
Thomas Monjalon Sept. 17, 2018, 2:36 p.m. UTC | #7 
17/09/2018 16:13, Joseph, Anoob:
> On 17-09-2018 17:50, Akhil Goyal wrote:
> > On 9/17/2018 5:12 PM, Joseph, Anoob wrote:
> >> On 17-09-2018 16:07, Akhil Goyal wrote:
> >>>>> I think it would be better to squash the makefile related changes in
> >>>>> the 3/33 patch as the code
> >>>>> is actually added in that and here the code is not getting compiled
> >>>>> here.
> >>>> So the changes in the following files has to be moved to patch 3/33?
> >>>>    drivers/crypto/Makefile
> >>>>    drivers/crypto/meson.build
> >>>>    drivers/crypto/octeontx/Makefile
> >>>>    drivers/crypto/octeontx/meson.build
> >>>>    mk/rte.app.mk
> >>>> I think this patch will just have MAINTAINER edit (even that might be
> >>>> required to be moved to 3/33?) & changes to config/common_base, after
> >>>> that. Is that fine?
> >>> In my opinion, you do not need this patch as separate one.
> >>> config/common_base can also be added in the 3/33.
> >> In that case 02/33 patch would become the first patch right? The same
> >> problem would be there too, I guess. The macros added in that patch gets
> >> used only in 03/33 patch. Is that fine?
> >
> > I think that would be fine. Better to have a 03/33 patch before 02/33 
> > if it doesn't have dependencies.
> 03/33 patch is dependent on 02/33 patch. Shall I proceed with merging 
> 01/33 to 03/33 and make 02/33 the first patch?

You should start by introducing common code directory.
Then you introduce the PMD directory with minimal code in it.

Question: what means "cpt"?
Why it is not an "octeontx" common directory?
Anoob Joseph Sept. 17, 2018, 2:50 p.m. UTC | #8 
Hi Thomas,


On 17-09-2018 20:06, Thomas Monjalon wrote:
> External Email
>
> 17/09/2018 16:13, Joseph, Anoob:
>> On 17-09-2018 17:50, Akhil Goyal wrote:
>>> On 9/17/2018 5:12 PM, Joseph, Anoob wrote:
>>>> On 17-09-2018 16:07, Akhil Goyal wrote:
>>>>>>> I think it would be better to squash the makefile related changes in
>>>>>>> the 3/33 patch as the code
>>>>>>> is actually added in that and here the code is not getting compiled
>>>>>>> here.
>>>>>> So the changes in the following files has to be moved to patch 3/33?
>>>>>>     drivers/crypto/Makefile
>>>>>>     drivers/crypto/meson.build
>>>>>>     drivers/crypto/octeontx/Makefile
>>>>>>     drivers/crypto/octeontx/meson.build
>>>>>>     mk/rte.app.mk
>>>>>> I think this patch will just have MAINTAINER edit (even that might be
>>>>>> required to be moved to 3/33?) & changes to config/common_base, after
>>>>>> that. Is that fine?
>>>>> In my opinion, you do not need this patch as separate one.
>>>>> config/common_base can also be added in the 3/33.
>>>> In that case 02/33 patch would become the first patch right? The same
>>>> problem would be there too, I guess. The macros added in that patch gets
>>>> used only in 03/33 patch. Is that fine?
>>> I think that would be fine. Better to have a 03/33 patch before 02/33
>>> if it doesn't have dependencies.
>> 03/33 patch is dependent on 02/33 patch. Shall I proceed with merging
>> 01/33 to 03/33 and make 02/33 the first patch?
> You should start by introducing common code directory.
> Then you introduce the PMD directory with minimal code in it.
Understood.
> Question: what means "cpt"?
> Why it is not an "octeontx" common directory?
CPT is the cryptographic engine in OcteonTX family. This dir will have 
the common code that will be shared between octeontx and other 
processors with similar engine. The directory "common/octeontx" is for 
common code shared by different components of the same chip(octeontx). 
Here it's the code for same engine across multiple platforms.

Anoob
Akhil Goyal Sept. 18, 2018, 12:31 p.m. UTC | #9 
Hi Anoob,

On 9/17/2018 7:43 PM, Joseph, Anoob wrote:
> Hi Akhil,
>
>
> On 17-09-2018 17:50, Akhil Goyal wrote:
>> External Email
>>
>> On 9/17/2018 5:12 PM, Joseph, Anoob wrote:
>>
>>> Hi Akhil,
>>> On 17-09-2018 16:07, Akhil Goyal wrote:
>>>> External Email
>>>>>> I think it would be better to squash the makefile related changes in
>>>>>> the 3/33 patch as the code
>>>>>> is actually added in that and here the code is not getting compiled
>>>>>> here.
>>>>> So the changes in the following files has to be moved to patch 3/33?
>>>>>    drivers/crypto/Makefile
>>>>>    drivers/crypto/meson.build
>>>>>    drivers/crypto/octeontx/Makefile
>>>>>    drivers/crypto/octeontx/meson.build
>>>>>    mk/rte.app.mk
>>>>> I think this patch will just have MAINTAINER edit (even that might be
>>>>> required to be moved to 3/33?) & changes to config/common_base, after
>>>>> that. Is that fine?
>>>> In my opinion, you do not need this patch as separate one.
>>>> config/common_base can also be added in the 3/33.
>>> In that case 02/33 patch would become the first patch right? The same
>>> problem would be there too, I guess. The macros added in that patch 
>>> gets
>>> used only in 03/33 patch. Is that fine?
>>
>> I think that would be fine. Better to have a 03/33 patch before 02/33 
>> if it doesn't have dependencies.
> 03/33 patch is dependent on 02/33 patch. Shall I proceed with merging 
> 01/33 to 03/33 and make 02/33 the first patch?
>>
>>> The first patch would be a shell patch for most PMD additions. That's
>>> the reason we started this way. If you want it changed, will do so.
>>> Please do let me know what will be the right approach.
>>
>> For the makefiles, you would be compiling the empty files which does 
>> not have any code. That does not make any sense to me.
> With 01/33 there won't be any files compiled. We are just adding the 
> library (which would be empty)
>>
>> Normally, when we submit a new PMD, we add the basic PMD probe/remove 
>> in the first patch and add it into build system. Maintainers is also 
>> updated for the new PMD.
>>
>> Further ops are added later in the patchset.
>>
>> Hardware specific header files/ functions are added before they are 
>> used in the driver in a single/multiple logical patches.
>>
>> In the end, documentation is added along with release note and 
>> MAINTAINERS update for documentation files.
> I shall proceed with merging 01/33 to 03/33, if you can confirm making 
> 02/33 the first patch is fine. Or please do let me know if you have 
> any other suggestions.
>
I see that the 2/33 is adding the logging macros. I believe that can 
also be merged in the 03/33.
Also I missed one comment on the documentation patch.. Please add your 
pmd doc entry in index.rst as well.
> Anoob
>
Joseph@dpdk.org Sept. 18, 2018, 12:40 p.m. UTC | #10 
Hi Akhil,

On 18-09-2018 18:01, Akhil Goyal wrote:
> External Email
>
> Hi Anoob,
>
> On 9/17/2018 7:43 PM, Joseph, Anoob wrote:
>> Hi Akhil,
>>
>>
>> On 17-09-2018 17:50, Akhil Goyal wrote:
>>> External Email
>>>
>>> On 9/17/2018 5:12 PM, Joseph, Anoob wrote:
>>>
>>>> Hi Akhil,
>>>> On 17-09-2018 16:07, Akhil Goyal wrote:
>>>>> External Email
>>>>>>> I think it would be better to squash the makefile related 
>>>>>>> changes in
>>>>>>> the 3/33 patch as the code
>>>>>>> is actually added in that and here the code is not getting compiled
>>>>>>> here.
>>>>>> So the changes in the following files has to be moved to patch 3/33?
>>>>>>    drivers/crypto/Makefile
>>>>>>    drivers/crypto/meson.build
>>>>>>    drivers/crypto/octeontx/Makefile
>>>>>>    drivers/crypto/octeontx/meson.build
>>>>>>    mk/rte.app.mk
>>>>>> I think this patch will just have MAINTAINER edit (even that 
>>>>>> might be
>>>>>> required to be moved to 3/33?) & changes to config/common_base, 
>>>>>> after
>>>>>> that. Is that fine?
>>>>> In my opinion, you do not need this patch as separate one.
>>>>> config/common_base can also be added in the 3/33.
>>>> In that case 02/33 patch would become the first patch right? The same
>>>> problem would be there too, I guess. The macros added in that patch
>>>> gets
>>>> used only in 03/33 patch. Is that fine?
>>>
>>> I think that would be fine. Better to have a 03/33 patch before 02/33
>>> if it doesn't have dependencies.
>> 03/33 patch is dependent on 02/33 patch. Shall I proceed with merging
>> 01/33 to 03/33 and make 02/33 the first patch?
>>>
>>>> The first patch would be a shell patch for most PMD additions. That's
>>>> the reason we started this way. If you want it changed, will do so.
>>>> Please do let me know what will be the right approach.
>>>
>>> For the makefiles, you would be compiling the empty files which does
>>> not have any code. That does not make any sense to me.
>> With 01/33 there won't be any files compiled. We are just adding the
>> library (which would be empty)
>>>
>>> Normally, when we submit a new PMD, we add the basic PMD probe/remove
>>> in the first patch and add it into build system. Maintainers is also
>>> updated for the new PMD.
>>>
>>> Further ops are added later in the patchset.
>>>
>>> Hardware specific header files/ functions are added before they are
>>> used in the driver in a single/multiple logical patches.
>>>
>>> In the end, documentation is added along with release note and
>>> MAINTAINERS update for documentation files.
>> I shall proceed with merging 01/33 to 03/33, if you can confirm making
>> 02/33 the first patch is fine. Or please do let me know if you have
>> any other suggestions.
>>
> I see that the 2/33 is adding the logging macros. I believe that can
> also be merged in the 03/33.
./devtools/check-git-log.sh was giving me issues when one patch was 
having edits in both drivers/common/cpt & drivers/crypto/octeontx. 
That's the reason it was separated out. Many patches had to be divided 
because of this.
> Also I missed one comment on the documentation patch.. Please add your
> pmd doc entry in index.rst as well.
Will fix this in v3.

Thanks,
Anoob
Akhil Goyal Sept. 18, 2018, 12:44 p.m. UTC | #11 
On 9/18/2018 6:10 PM, Joseph@dpdk.org wrote:
> Hi Akhil,
>
> On 18-09-2018 18:01, Akhil Goyal wrote:
>> External Email
>>
>> Hi Anoob,
>>
>> On 9/17/2018 7:43 PM, Joseph, Anoob wrote:
>>> Hi Akhil,
>>>
>>>
>>> On 17-09-2018 17:50, Akhil Goyal wrote:
>>>> External Email
>>>>
>>>> On 9/17/2018 5:12 PM, Joseph, Anoob wrote:
>>>>
>>>>> Hi Akhil,
>>>>> On 17-09-2018 16:07, Akhil Goyal wrote:
>>>>>> External Email
>>>>>>>> I think it would be better to squash the makefile related
>>>>>>>> changes in
>>>>>>>> the 3/33 patch as the code
>>>>>>>> is actually added in that and here the code is not getting compiled
>>>>>>>> here.
>>>>>>> So the changes in the following files has to be moved to patch 3/33?
>>>>>>>     drivers/crypto/Makefile
>>>>>>>     drivers/crypto/meson.build
>>>>>>>     drivers/crypto/octeontx/Makefile
>>>>>>>     drivers/crypto/octeontx/meson.build
>>>>>>>     mk/rte.app.mk
>>>>>>> I think this patch will just have MAINTAINER edit (even that
>>>>>>> might be
>>>>>>> required to be moved to 3/33?) & changes to config/common_base,
>>>>>>> after
>>>>>>> that. Is that fine?
>>>>>> In my opinion, you do not need this patch as separate one.
>>>>>> config/common_base can also be added in the 3/33.
>>>>> In that case 02/33 patch would become the first patch right? The same
>>>>> problem would be there too, I guess. The macros added in that patch
>>>>> gets
>>>>> used only in 03/33 patch. Is that fine?
>>>> I think that would be fine. Better to have a 03/33 patch before 02/33
>>>> if it doesn't have dependencies.
>>> 03/33 patch is dependent on 02/33 patch. Shall I proceed with merging
>>> 01/33 to 03/33 and make 02/33 the first patch?
>>>>> The first patch would be a shell patch for most PMD additions. That's
>>>>> the reason we started this way. If you want it changed, will do so.
>>>>> Please do let me know what will be the right approach.
>>>> For the makefiles, you would be compiling the empty files which does
>>>> not have any code. That does not make any sense to me.
>>> With 01/33 there won't be any files compiled. We are just adding the
>>> library (which would be empty)
>>>> Normally, when we submit a new PMD, we add the basic PMD probe/remove
>>>> in the first patch and add it into build system. Maintainers is also
>>>> updated for the new PMD.
>>>>
>>>> Further ops are added later in the patchset.
>>>>
>>>> Hardware specific header files/ functions are added before they are
>>>> used in the driver in a single/multiple logical patches.
>>>>
>>>> In the end, documentation is added along with release note and
>>>> MAINTAINERS update for documentation files.
>>> I shall proceed with merging 01/33 to 03/33, if you can confirm making
>>> 02/33 the first patch is fine. Or please do let me know if you have
>>> any other suggestions.
>>>
>> I see that the 2/33 is adding the logging macros. I believe that can
>> also be merged in the 03/33.
> ./devtools/check-git-log.sh was giving me issues when one patch was
> having edits in both drivers/common/cpt & drivers/crypto/octeontx.
> That's the reason it was separated out. Many patches had to be divided
> because of this.
Oh,  my bad... I missed that this is a separate driver. I thought it was 
for the same driver.
It would be fine to have 02/33 as your first patch as Thomas also suggested.
>> Also I missed one comment on the documentation patch.. Please add your
>> pmd doc entry in index.rst as well.
> Will fix this in v3.
>
> Thanks,
> Anoob
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 9fd258f..09548fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -771,6 +771,13 @@  F: drivers/crypto/armv8/
 F: doc/guides/cryptodevs/armv8.rst
 F: doc/guides/cryptodevs/features/armv8.ini
 
+Cavium OcteonTX
+M: Anoob Joseph <anoob.joseph@caviumnetworks.com>
+F: drivers/common/cpt/
+F: drivers/crypto/octeontx/
+F: doc/guides/cryptodevs/octeontx.rst
+F: doc/guides/cryptodevs/features/octeontx.ini
+
 Crypto Scheduler
 M: Fan Zhang <roy.fan.zhang@intel.com>
 F: drivers/crypto/scheduler/
diff --git a/config/common_base b/config/common_base
index 4bcbaf9..4c6a951 100644
--- a/config/common_base
+++ b/config/common_base
@@ -635,6 +635,11 @@  CONFIG_RTE_LIBRTE_PMD_DPAA_EVENTDEV=n
 CONFIG_RTE_LIBRTE_PMD_DPAA2_EVENTDEV=n
 
 #
+# Compile PMD for Cavium OcteonTX crypto device
+#
+CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO=y
+
+#
 # Compile raw device support
 # EXPERIMENTAL: API may change without prior notice
 #
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c480cbd..c083e64 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -7,6 +7,7 @@  DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_GCM) += aesni_gcm
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += aesni_mb
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO) += armv8
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_CCP) += ccp
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += octeontx
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_OPENSSL) += openssl
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += scheduler
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_SNOW3G) += snow3g
diff --git a/drivers/crypto/meson.build b/drivers/crypto/meson.build
index d64ca41..2187870 100644
--- a/drivers/crypto/meson.build
+++ b/drivers/crypto/meson.build
@@ -2,7 +2,7 @@ 
 # Copyright(c) 2017 Intel Corporation
 
 drivers = ['ccp', 'dpaa_sec', 'dpaa2_sec', 'mvsam',
-	'null', 'openssl', 'qat', 'virtio']
+	'null', 'octeontx', 'openssl', 'qat', 'virtio']
 
 std_deps = ['cryptodev'] # cryptodev pulls in all other needed deps
 config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
diff --git a/drivers/crypto/octeontx/Makefile b/drivers/crypto/octeontx/Makefile
new file mode 100644
index 0000000..65bd02f
--- /dev/null
+++ b/drivers/crypto/octeontx/Makefile
@@ -0,0 +1,37 @@ 
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 Cavium, Inc
+#
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# library name
+LIB = librte_pmd_octeontx_crypto.a
+
+# library version
+LIBABIVER := 1
+
+# build flags
+CFLAGS += $(WERROR_FLAGS)
+
+LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
+LDLIBS += -lrte_cryptodev
+LDLIBS += -lrte_pci -lrte_bus_pci
+
+VPATH += $(RTE_SDK)/drivers/crypto/octeontx
+
+CFLAGS += -O3 -DCPT_MODEL=CRYPTO_OCTEONTX
+
+# export include files
+SYMLINK-y-include +=
+
+# versioning export map
+EXPORT_MAP := rte_pmd_octeontx_crypto_version.map
+
+# library dependencies
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_eal
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_cryptodev
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_mempool
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += lib/librte_malloc
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/crypto/octeontx/meson.build b/drivers/crypto/octeontx/meson.build
new file mode 100644
index 0000000..261bb77
--- /dev/null
+++ b/drivers/crypto/octeontx/meson.build
@@ -0,0 +1,12 @@ 
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2018 Cavium, Inc
+if host_machine.system() != 'linux'
+	build = false
+endif
+
+deps += ['bus_pci']
+name = 'octeontx_crypto'
+
+sources = files()
+
+cflags += '-DCPT_MODEL=CRYPTO_OCTEONTX'
diff --git a/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
new file mode 100644
index 0000000..521e51f
--- /dev/null
+++ b/drivers/crypto/octeontx/rte_pmd_octeontx_crypto_version.map
@@ -0,0 +1,4 @@ 
+DPDK_18.11 {
+
+	local: *;
+};
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index de33883..b530337 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -211,6 +211,7 @@  _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ZUC)         += -L$(LIBSSO_ZUC_PATH)/build -lsso
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO)    += -lrte_pmd_armv8
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO)    += -L$(ARMV8_CRYPTO_LIB_PATH) -larmv8_crypto
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_MVSAM_CRYPTO) += -L$(LIBMUSDK_PATH)/lib -lrte_pmd_mvsam_crypto -lmusdk
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO) += -lrte_pmd_octeontx_crypto
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER) += -lrte_pmd_crypto_scheduler
 ifeq ($(CONFIG_RTE_EAL_VFIO)$(CONFIG_RTE_LIBRTE_FSLMC_BUS),yy)
 _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_SEC)   += -lrte_pmd_dpaa2_sec