October 2022 - Acc - mailweb.openeuler.org

[PATCH v6 0/6] uadk - add wd_comp_init2
by Yang Shen 02 Nov '22

02 Nov '22

The current uadk initialization process is: 1.Call wd_request_ctx() to request ctxs from devices. 2.Call wd_sched_rr_alloc() to create a sched(or some other scheduler alloc function if exits). 3.Initialize the sched. 4.Call wd_<alg>_init() with ctx_config and sched. Logic is reasonable. But in practice, the step of `wd_ request_ Ctx() ` and `wd_ sched_ rr_alloc() ` are very tedious. This makes it difficult for users to use the interface. One of the main reasons for this is that uadk has made a lot of configurations in the scheduler in order to provide users with better performance. Based on this consideration, the current uadk requires the user to arrange the division of hardware resources according to the device topology during initialization. Therefore, as a high-level interface, this scheme can provide customized scheme configuration for users with deep needs. All algorithm initialization interfaces have the same input parameters and behavioral logic. The pre-processing of the wd_<alg>_init is actually the configuration of `struct wd_ctx_config` and `struct wd_sched`. Therefore, the next thing to be done is to use limited and easy-to-use input parameters to describe users' requirements on the two input parameters, ensuring that the functions of the new interface init2 are the same as those of init. For ease of description, v1 is used to refer to the existing interface, and v2 is used to refer to the layer of encapsulation. At present, at least 4 parameters are required to meet the user configuration requirements with the V1 interface function remains unchanged. @alg: The algorithm users wanted. @sched_type: Scheduling type the user wants to use. @task_tp: Reserved. @wd_ctx_params: op_type_num and ctx_set_num means the requested ctx number for each numa node. Due to users may have different requirements for different types of ctx numbers, needs a two-dimensional array as input. The bitmask provided by libnuma. Users can use this parameter to control requesting ctxs devices in the bind NUMA scenario. This parameter is mainly convenient for users to use in the binding cpu scenario. It can avoid resource waste or initialization failure caused by insufficient resources. Libnuma provides a complete operation interface which can be found in numa.h. Changelog: v5->v6: - Update a limit between wd_comp_init() and wd_comp_init2_(). If the wd_comp_init2_() is called after wd_comp_init(), some ctx resources may be leak until called wd_comp_uninit2(). v4->v5: - Update wd_comp_init2() and wd_comp_init2_() parameters. v3->v4: - Resume the wd_comp_init2() parameters and rename it to wd_comp_init2_(). Then add a macro named wd_comp_init2() which has a simpler parameters. v2->v3: - Update the wd_comp_init2() parameters. v1->v2: - Update the desdescription about wd_<alg>_init in wd_design.md. Yang Shen (6): uadk - support algorithms initialization reentry protect uadk/doc - update wd_alg_init support reentrancy uadk - support return error number as pointer uadk - mv some function to header file uadk/comp - add wd_comp_init2 uadk/docs - support a simple interface for initialization Makefile.am | 4 +- docs/wd_alg_init2.md | 159 ++++++++++++++++++++++++ docs/wd_design.md | 5 +- include/wd.h | 54 ++++++++- include/wd_alg_common.h | 27 +++++ include/wd_comp.h | 30 +++++ include/wd_util.h | 66 ++++++++++ wd.c | 97 ++++++++++++--- wd_aead.c | 33 +++-- wd_cipher.c | 35 ++++-- wd_comp.c | 129 ++++++++++++++++++-- wd_dh.c | 34 ++++-- wd_digest.c | 33 +++-- wd_ecc.c | 33 +++-- wd_rsa.c | 33 +++-- wd_util.c | 260 +++++++++++++++++++++++++++++++++++++++- 16 files changed, 926 insertions(+), 106 deletions(-) create mode 100644 docs/wd_alg_init2.md -- 2.24.0

3 12

FSC
by Ms K. Ngui 01 Nov '22

01 Nov '22

Kindly confirm if your email (][-Email-]]) is still active ? the reason for my question is because i am yet to recieved a reply in regards to my message sent to your email earlier this week. Thanks Mrs Karen Ngui GMD - DBS

1 0

[PATCH v5 0/6] uadk - add wd_comp_init2
by Yang Shen 29 Oct '22

29 Oct '22

The current uadk initialization process is: 1.Call wd_request_ctx() to request ctxs from devices. 2.Call wd_sched_rr_alloc() to create a sched(or some other scheduler alloc function if exits). 3.Initialize the sched. 4.Call wd_<alg>_init() with ctx_config and sched. Logic is reasonable. But in practice, the step of `wd_ request_ Ctx() ` and `wd_ sched_ rr_alloc() ` are very tedious. This makes it difficult for users to use the interface. One of the main reasons for this is that uadk has made a lot of configurations in the scheduler in order to provide users with better performance. Based on this consideration, the current uadk requires the user to arrange the division of hardware resources according to the device topology during initialization. Therefore, as a high-level interface, this scheme can provide customized scheme configuration for users with deep needs. All algorithm initialization interfaces have the same input parameters and behavioral logic. The pre-processing of the wd_<alg>_init is actually the configuration of `struct wd_ctx_config` and `struct wd_sched`. Therefore, the next thing to be done is to use limited and easy-to-use input parameters to describe users' requirements on the two input parameters, ensuring that the functions of the new interface init2 are the same as those of init. For ease of description, v1 is used to refer to the existing interface, and v2 is used to refer to the layer of encapsulation. At present, at least 4 parameters are required to meet the user configuration requirements with the V1 interface function remains unchanged. @alg: The algorithm users wanted. @sched_type: Scheduling type the user wants to use. @task_tp: Reserved. @wd_ctx_params: op_type_num and ctx_set_num means the requested ctx number for each numa node. Due to users may have different requirements for different types of ctx numbers, needs a two-dimensional array as input. The bitmask provided by libnuma. Users can use this parameter to control requesting ctxs devices in the bind NUMA scenario. This parameter is mainly convenient for users to use in the binding cpu scenario. It can avoid resource waste or initialization failure caused by insufficient resources. Libnuma provides a complete operation interface which can be found in numa.h. Changelog: v4->v5: - Update wd_comp_init2() and wd_comp_init2_() parameters. v3->v4: - Resume the wd_comp_init2() parameters and rename it to wd_comp_init2_(). Then add a macro named wd_comp_init2() which has a simpler parameters. v2->v3: - Update the wd_comp_init2() parameters. v1->v2: - Update the desdescription about wd_<alg>_init in wd_design.md. Yang Shen (6): uadk - support algorithms initialization reentry protect uadk/doc - update wd_alg_init support reentrancy uadk - support return error number as pointer uadk - mv some function to header file uadk/comp - add wd_comp_init2 uadk/docs - support a simple interface for initialization Makefile.am | 4 +- docs/wd_alg_init2.md | 156 ++++++++++++++++++++++++ docs/wd_design.md | 5 +- include/wd.h | 54 ++++++++- include/wd_alg_common.h | 27 +++++ include/wd_comp.h | 28 +++++ include/wd_util.h | 56 +++++++++ wd.c | 97 ++++++++++++--- wd_aead.c | 33 +++-- wd_cipher.c | 35 ++++-- wd_comp.c | 122 +++++++++++++++++-- wd_dh.c | 34 ++++-- wd_digest.c | 33 +++-- wd_ecc.c | 33 +++-- wd_rsa.c | 33 +++-- wd_util.c | 260 +++++++++++++++++++++++++++++++++++++++- 16 files changed, 904 insertions(+), 106 deletions(-) create mode 100644 docs/wd_alg_init2.md -- 2.24.0

1 6

[PATCH v4 0/6] uadk - add wd_comp_init2
by Yang Shen 28 Oct '22

28 Oct '22

The current uadk initialization process is: 1.Call wd_request_ctx() to request ctxs from devices. 2.Call wd_sched_rr_alloc() to create a sched(or some other scheduler alloc function if exits). 3.Initialize the sched. 4.Call wd_<alg>_init() with ctx_config and sched. Logic is reasonable. But in practice, the step of `wd_ request_ Ctx() ` and `wd_ sched_ rr_alloc() ` are very tedious. This makes it difficult for users to use the interface. One of the main reasons for this is that uadk has made a lot of configurations in the scheduler in order to provide users with better performance. Based on this consideration, the current uadk requires the user to arrange the division of hardware resources according to the device topology during initialization. Therefore, as a high-level interface, this scheme can provide customized scheme configuration for users with deep needs. All algorithm initialization interfaces have the same input parameters and behavioral logic. The pre-processing of the wd_<alg>_init is actually the configuration of `struct wd_ctx_config` and `struct wd_sched`. Therefore, the next thing to be done is to use limited and easy-to-use input parameters to describe users' requirements on the two input parameters, ensuring that the functions of the new interface init2 are the same as those of init. For ease of description, v1 is used to refer to the existing interface, and v2 is used to refer to the layer of encapsulation. At present, at least 4 parameters are required to meet the user configuration requirements with the V1 interface function remains unchanged. @device_list: The available uacce device list. Users can get it by wd_get_accel_list(). @numa_bitmask: The bitmask provided by libnuma. Users can use this parameter to control requesting ctxs devices in the bind NUMA scenario. @ctx_nums: The requested ctx number for each numa node. Due to users may have different requirements for different types of ctx numbers, needs a two-dimensional array as input. @sched_type: Scheduling type the user wants to use. What's more, some users want uadk to provide the default value about input parameters for some performance insensitive scenes. C code has no way to. Changelog: v3->v4: - Resume the wd_comp_init2() parameters and rename it to wd_comp_init2_(). Then add a macro named wd_comp_init2() which has a simpler parameters. v2->v3: - Update the wd_comp_init2() parameters. v1->v2: - Update the desdescription about wd_<alg>_init in wd_design.md. Yang Shen (6): uadk - support algorithms initialization reentry protect uadk/doc - update wd_alg_init support reentrancy uadk - support return error number as pointer uadk - mv some function to header file uadk/comp - add wd_comp_init2 uadk/docs - support a simple interface for initialization Makefile.am | 4 +- docs/wd_alg_init2.md | 154 ++++++++++++++++++++++++ docs/wd_design.md | 5 +- include/wd.h | 54 ++++++++- include/wd_alg_common.h | 24 ++++ include/wd_comp.h | 27 +++++ include/wd_util.h | 57 +++++++++ wd.c | 97 ++++++++++++--- wd_aead.c | 33 +++-- wd_cipher.c | 35 ++++-- wd_comp.c | 121 +++++++++++++++++-- wd_dh.c | 34 ++++-- wd_digest.c | 33 +++-- wd_ecc.c | 33 +++-- wd_rsa.c | 33 +++-- wd_util.c | 260 +++++++++++++++++++++++++++++++++++++++- 16 files changed, 898 insertions(+), 106 deletions(-) create mode 100644 docs/wd_alg_init2.md -- 2.24.0

2 8

[PATCH v7 0/6] crypto/uadk: introduce uadk crypto driver
by Zhangfei Gao 28 Oct '22

28 Oct '22

Introduce a new crypto PMD for hardware accelerators based on UADK [1]. UADK is a framework for user applications to access hardware accelerators. UADK relies on IOMMU SVA (Shared Virtual Address) feature, which share the same page table between IOMMU and MMU. Thereby user application can directly use virtual address for device dma, which enhances the performance as well as easy usability. [1] https://github.com/Linaro/uadk Test: sudo dpdk-test --vdev=crypto_uadk (--log-level=6) RTE>>cryptodev_uadk_autotest RTE>>quit Update in v7: 05: fix key_size of SHA384 HMAC Update in v6: Akhil helped review the v5, and address all the comments from Akhil 01: add rel_notes info, update uadk.rst, put struct in header, etc. 02: move struct to header 04: move struct to header, remove RTE_CRYPTODEV_FF_SYM_SESSIONLESS 05: fixed key_size in HMAC mode 06: updated app/test/meson.build and uadk.rst in the mean time. Update in v5 Patch 1 fix the build issue when uadk is installed to specific folder And update doc accordingly Update in v4: Akril suggest dpdk use pkg-config, So Enable uadk support x86 local build, and support pkg-config. Use pkg-config feature for the uadk crypto pmd. Add build uadk library steps in doc Test on both x86 and arm. x86 can build and install, but can not test since no device. Resend v3: Rebase on next/for-main, which just merged the series "cryptodev: rework session framework". Update in v3: Split patches according to Akhil's suggestions Please split the patches as below. 1. introduce driver - create files with meson.build and with probe/remove and device ops defined but not implemented. You do not need to write empty functions. Add basic documentation also which defines what the driver is. You can explain the build dependency here. 2. define queue structs and setup/remove APIs 3. Add data path 4. implement cipher op. Add capabilities and documentation of what is supported in each of the patches. Add feature flags etc. 5. implement auth, add capabilities and documentation 6. test app changes. Update in v2: Change uadk_supported_platform to uadk_crypto_version, which matches better than platform. enum uadk_crypto_version { UADK_CRYPTO_V2, UADK_CRYPTO_V3, }; Update in v1, compared with rfc Suggested from Akhil Goyal <gakhil(a)marvell.com> Only consider crypto PMD first Split patch into small (individually compiled) patches. Update MAINTAINERS and doc/guides/cryptodevs/features/uadk.ini Zhangfei Gao (6): crypto/uadk: introduce uadk crypto driver crypto/uadk: support basic operations crypto/uadk: support enqueue/dequeue operations crypto/uadk: support cipher algorithms crypto/uadk: support auth algorithms test/crypto: support uadk PMD MAINTAINERS | 6 + app/test/meson.build | 1 + app/test/test_cryptodev.c | 7 + app/test/test_cryptodev.h | 1 + doc/guides/cryptodevs/features/uadk.ini | 55 + doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/uadk.rst | 96 ++ doc/guides/rel_notes/release_22_11.rst | 6 + drivers/crypto/meson.build | 1 + drivers/crypto/uadk/meson.build | 30 + drivers/crypto/uadk/uadk_crypto_pmd.c | 1081 +++++++++++++++++ drivers/crypto/uadk/uadk_crypto_pmd_private.h | 79 ++ drivers/crypto/uadk/version.map | 3 + 13 files changed, 1367 insertions(+) create mode 100644 doc/guides/cryptodevs/features/uadk.ini create mode 100644 doc/guides/cryptodevs/uadk.rst create mode 100644 drivers/crypto/uadk/meson.build create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd.c create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd_private.h create mode 100644 drivers/crypto/uadk/version.map -- 2.25.1

2 8

[PATCH v6 0/6] crypto/uadk: introduce uadk crypto driver
by Zhangfei Gao 27 Oct '22

27 Oct '22

Introduce a new crypto PMD for hardware accelerators based on UADK [1]. UADK is a framework for user applications to access hardware accelerators. UADK relies on IOMMU SVA (Shared Virtual Address) feature, which share the same page table between IOMMU and MMU. Thereby user application can directly use virtual address for device dma, which enhances the performance as well as easy usability. [1] https://github.com/Linaro/uadk Test: sudo dpdk-test --vdev=crypto_uadk (--log-level=6) RTE>>cryptodev_uadk_autotest RTE>>quit Update in v6: Akhil helped review the v5, and address all the comments from Akhil 01: add rel_notes info, update uadk.rst, put struct in header, etc. 02: move struct to header 04: move struct to header, remove RTE_CRYPTODEV_FF_SYM_SESSIONLESS 05: fixed key_size in HMAC mode 06: updated app/test/meson.build and uadk.rst in the mean time. Update in v5 Patch 1 fix the build issue when uadk is installed to specific folder And update doc accordingly Update in v4: Akril suggest dpdk use pkg-config, So Enable uadk support x86 local build, and support pkg-config. Use pkg-config feature for the uadk crypto pmd. Add build uadk library steps in doc Test on both x86 and arm. x86 can build and install, but can not test since no device. Resend v3: Rebase on next/for-main, which just merged the series "cryptodev: rework session framework". Update in v3: Split patches according to Akhil's suggestions Please split the patches as below. 1. introduce driver - create files with meson.build and with probe/remove and device ops defined but not implemented. You do not need to write empty functions. Add basic documentation also which defines what the driver is. You can explain the build dependency here. 2. define queue structs and setup/remove APIs 3. Add data path 4. implement cipher op. Add capabilities and documentation of what is supported in each of the patches. Add feature flags etc. 5. implement auth, add capabilities and documentation 6. test app changes. Update in v2: Change uadk_supported_platform to uadk_crypto_version, which matches better than platform. enum uadk_crypto_version { UADK_CRYPTO_V2, UADK_CRYPTO_V3, }; Update in v1, compared with rfc Suggested from Akhil Goyal <gakhil(a)marvell.com> Only consider crypto PMD first Split patch into small (individually compiled) patches. Update MAINTAINERS and doc/guides/cryptodevs/features/uadk.ini Zhangfei Gao (6): crypto/uadk: introduce uadk crypto driver crypto/uadk: support basic operations crypto/uadk: support enqueue/dequeue operations crypto/uadk: support cipher algorithms crypto/uadk: support auth algorithms test/crypto: support uadk PMD MAINTAINERS | 6 + app/test/meson.build | 1 + app/test/test_cryptodev.c | 7 + app/test/test_cryptodev.h | 1 + doc/guides/cryptodevs/features/uadk.ini | 55 + doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/uadk.rst | 96 ++ doc/guides/rel_notes/release_22_11.rst | 6 + drivers/crypto/meson.build | 1 + drivers/crypto/uadk/meson.build | 30 + drivers/crypto/uadk/uadk_crypto_pmd.c | 1075 +++++++++++++++++ drivers/crypto/uadk/uadk_crypto_pmd_private.h | 79 ++ drivers/crypto/uadk/version.map | 3 + 13 files changed, 1361 insertions(+) create mode 100644 doc/guides/cryptodevs/features/uadk.ini create mode 100644 doc/guides/cryptodevs/uadk.rst create mode 100644 drivers/crypto/uadk/meson.build create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd.c create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd_private.h create mode 100644 drivers/crypto/uadk/version.map -- 2.38.1

2 8

[PATCH resend v5 0/6] crypto/uadk: introduce uadk crypto driver
by Zhangfei Gao 26 Oct '22

26 Oct '22

Introduce a new crypto PMD for hardware accelerators based on UADK [1]. UADK is a framework for user applications to access hardware accelerators. UADK relies on IOMMU SVA (Shared Virtual Address) feature, which share the same page table between IOMMU and MMU. Thereby user application can directly use virtual address for device dma, which enhances the performance as well as easy usability. [1] https://github.com/Linaro/uadk Test: sudo dpdk-test --vdev=crypto_uadk (--log-level=6) RTE>>cryptodev_uadk_autotest RTE>>quit resend: fix uadk lib, still use <uadk/wd_cipher.h> Update in v5 Patch 1 fix the build issue when uadk is installed to specific folder And update doc accordingly Update in v4: Akril suggest dpdk use pkg-config, So Enable uadk support x86 local build, and support pkg-config. Use pkg-config feature for the uadk crypto pmd. Add build uadk library steps in doc Test on both x86 and arm. x86 can build and install, but can not test since no device. Resend v3: Rebase on next/for-main, which just merged the series "cryptodev: rework session framework". Update in v3: Split patches according to Akhil's suggestions Please split the patches as below. 1. introduce driver - create files with meson.build and with probe/remove and device ops defined but not implemented. You do not need to write empty functions. Add basic documentation also which defines what the driver is. You can explain the build dependency here. 2. define queue structs and setup/remove APIs 3. Add data path 4. implement cipher op. Add capabilities and documentation of what is supported in each of the patches. Add feature flags etc. 5. implement auth, add capabilities and documentation 6. test app changes. Update in v2: Change uadk_supported_platform to uadk_crypto_version, which matches better than platform. enum uadk_crypto_version { UADK_CRYPTO_V2, UADK_CRYPTO_V3, }; Update in v1, compared with rfc Suggested from Akhil Goyal <gakhil(a)marvell.com> Only consider crypto PMD first Split patch into small (individually compiled) patches. Update MAINTAINERS and doc/guides/cryptodevs/features/uadk.ini Zhangfei Gao (6): crypto/uadk: introduce uadk crypto driver crypto/uadk: support basic operations crypto/uadk: support enqueue/dequeue operations crypto/uadk: support cipher algorithms crypto/uadk: support auth algorithms test/crypto: add cryptodev_uadk_autotest MAINTAINERS | 6 + app/test/test_cryptodev.c | 7 + app/test/test_cryptodev.h | 1 + doc/guides/cryptodevs/features/uadk.ini | 55 ++ doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/uadk.rst | 94 ++ drivers/crypto/meson.build | 1 + drivers/crypto/uadk/meson.build | 30 + drivers/crypto/uadk/uadk_crypto_pmd.c | 1141 +++++++++++++++++++++++ drivers/crypto/uadk/version.map | 3 + 10 files changed, 1339 insertions(+) create mode 100644 doc/guides/cryptodevs/features/uadk.ini create mode 100644 doc/guides/cryptodevs/uadk.rst create mode 100644 drivers/crypto/uadk/meson.build create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd.c create mode 100644 drivers/crypto/uadk/version.map -- 2.38.1

2 16

UADK双周例会
by openEuler conference 26 Oct '22

26 Oct '22

您好！ sig-AccLib SIG 邀请您参加 2022-10-26 11:00 召开的Zoom会议会议主题：UADK双周例会会议内容： zoom会议，ID: 91879279131 固定的会议链接：https://linaro-org.zoom.us/j/91879279131 1.进展讨论 2.pkg-config技术分享会议链接：https://us06web.zoom.us/j/81869388219?pwd=K0ltZk9kSTRUS2RSNFFnS3NKSDNodz09 会议纪要：https://etherpad.openeuler.org/p/sig-AccLib-meetings 温馨提醒：建议接入会议后修改参会人的姓名，也可以使用您在gitee.com的ID 更多资讯尽在：https://openeuler.org/zh/ Hello! openEuler sig-AccLib SIG invites you to attend the Zoom conference will be held at 2022-10-26 11:00, The subject of the conference is UADK双周例会, Summary: zoom会议，ID: 91879279131 固定的会议链接：https://linaro-org.zoom.us/j/91879279131 1.进展讨论 2.pkg-config技术分享 You can join the meeting at https://us06web.zoom.us/j/81869388219?pwd=K0ltZk9kSTRUS2RSNFFnS3NKSDNodz09. Add topics at https://etherpad.openeuler.org/p/sig-AccLib-meetings. Note: You are advised to change the participant name after joining the conference or use your ID at gitee.com. More information: https://openeuler.org/en/

1 0

[PATCH v4 0/6] crypto/uadk: introduce uadk crypto driver
by Zhangfei Gao 24 Oct '22

24 Oct '22

Introduce a new crypto PMD for hardware accelerators based on UADK [1]. UADK is a framework for user applications to access hardware accelerators. UADK relies on IOMMU SVA (Shared Virtual Address) feature, which share the same page table between IOMMU and MMU. Thereby user application can directly use virtual address for device dma, which enhances the performance as well as easy usability. [1] https://github.com/Linaro/uadk Test: sudo dpdk-test --vdev=crypto_uadk (--log-level=6) RTE>>cryptodev_uadk_autotest RTE>>quit Update in v4: Akril suggest dpdk use pkg-config, So Enable uadk support x86 local build, and support pkg-config. Use pkg-config feature for the uadk crypto pmd. Add build uadk library steps in doc Test on both x86 and arm. x86 can build and install, but can not test since no device. Resend v3: Rebase on next/for-main, which just merged the series "cryptodev: rework session framework". Update in v3: Split patches according to Akhil's suggestions Please split the patches as below. 1. introduce driver - create files with meson.build and with probe/remove and device ops defined but not implemented. You do not need to write empty functions. Add basic documentation also which defines what the driver is. You can explain the build dependency here. 2. define queue structs and setup/remove APIs 3. Add data path 4. implement cipher op. Add capabilities and documentation of what is supported in each of the patches. Add feature flags etc. 5. implement auth, add capabilities and documentation 6. test app changes. Update in v2: Change uadk_supported_platform to uadk_crypto_version, which matches better than platform. enum uadk_crypto_version { UADK_CRYPTO_V2, UADK_CRYPTO_V3, }; Update in v1, compared with rfc Suggested from Akhil Goyal <gakhil(a)marvell.com> Only consider crypto PMD first Split patch into small (individually compiled) patches. Update MAINTAINERS and doc/guides/cryptodevs/features/uadk.ini Zhangfei Gao (6): crypto/uadk: introduce uadk crypto driver crypto/uadk: support basic operations crypto/uadk: support enqueue/dequeue operations crypto/uadk: support cipher algorithms crypto/uadk: support auth algorithms test/crypto: add cryptodev_uadk_autotest MAINTAINERS | 6 + app/test/test_cryptodev.c | 7 + app/test/test_cryptodev.h | 1 + doc/guides/cryptodevs/features/uadk.ini | 55 ++ doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/uadk.rst | 88 ++ drivers/crypto/meson.build | 1 + drivers/crypto/uadk/meson.build | 30 + drivers/crypto/uadk/uadk_crypto_pmd.c | 1145 +++++++++++++++++++++++ drivers/crypto/uadk/version.map | 3 + 10 files changed, 1337 insertions(+) create mode 100644 doc/guides/cryptodevs/features/uadk.ini create mode 100644 doc/guides/cryptodevs/uadk.rst create mode 100644 drivers/crypto/uadk/meson.build create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd.c create mode 100644 drivers/crypto/uadk/version.map -- 2.36.1

2 12

[PATCH 00/10] uadk_engine: some bugfix and cleanup
by Zhiqi Song 21 Oct '22

21 Oct '22

This is a patch set about some bugfix and cleanup of uadk_engine. Hao Fang (1): uadk_engine: use HW_V2/HW_V3 to distinguish different hardware platforms. Longfang Liu (1): uadk/engine: Update the numa parameter of the scheduler Zhiqi Song (8): sm2: bugfix about segfault in sm2 ctrl function uadk_engine: bugfix side effects of right operand uadk_engine: cleanup avoid modify param of functions rsa: cleanup uninitialized value uadk_engine: cleanup storage class position uadk_engine: bugfix enable environment variable uadk_engine: cleanup magic number and comments uadk_engine: cleanup header file -- 2.30.0

1 10

[PATCH v5 0/6] crypto/uadk: introduce uadk crypto driver
by Zhangfei Gao 21 Oct '22

21 Oct '22

Introduce a new crypto PMD for hardware accelerators based on UADK [1]. UADK is a framework for user applications to access hardware accelerators. UADK relies on IOMMU SVA (Shared Virtual Address) feature, which share the same page table between IOMMU and MMU. Thereby user application can directly use virtual address for device dma, which enhances the performance as well as easy usability. [1] https://github.com/Linaro/uadk Test: sudo dpdk-test --vdev=crypto_uadk (--log-level=6) RTE>>cryptodev_uadk_autotest RTE>>quit Update in v5 Patch 1 fixes the build issue when uadk is installed to a specific folder And update doc accordingly Update in v4: Akril suggest dpdk use pkg-config, So Enable uadk support x86 local build, and support pkg-config. Use pkg-config feature for the uadk crypto pmd. Add build uadk library steps in doc Test on both x86 and arm. x86 can build and install, but can not test since no device. Resend v3: Rebase on next/for-main, which just merged the series "cryptodev: rework session framework". Update in v3: Split patches according to Akhil's suggestions Please split the patches as below. 1. introduce driver - create files with meson.build and with probe/remove and device ops defined but not implemented. You do not need to write empty functions. Add basic documentation also which defines what the driver is. You can explain the build dependency here. 2. define queue structs and setup/remove APIs 3. Add data path 4. implement cipher op. Add capabilities and documentation of what is supported in each of the patches. Add feature flags etc. 5. implement auth, add capabilities and documentation 6. test app changes. Update in v2: Change uadk_supported_platform to uadk_crypto_version, which matches better than platform. enum uadk_crypto_version { UADK_CRYPTO_V2, UADK_CRYPTO_V3, }; Update in v1, compared with rfc Suggested from Akhil Goyal <gakhil(a)marvell.com> Only consider crypto PMD first Split patch into small (individually compiled) patches. Update MAINTAINERS and doc/guides/cryptodevs/features/uadk.ini Zhangfei Gao (6): crypto/uadk: introduce uadk crypto driver crypto/uadk: support basic operations crypto/uadk: support enqueue/dequeue operations crypto/uadk: support cipher algorithms crypto/uadk: support auth algorithms test/crypto: add cryptodev_uadk_autotest MAINTAINERS | 6 + app/test/test_cryptodev.c | 7 + app/test/test_cryptodev.h | 1 + doc/guides/cryptodevs/features/uadk.ini | 55 ++ doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/uadk.rst | 94 ++ drivers/crypto/meson.build | 1 + drivers/crypto/uadk/meson.build | 30 + drivers/crypto/uadk/uadk_crypto_pmd.c | 1141 +++++++++++++++++++++++ drivers/crypto/uadk/version.map | 3 + 10 files changed, 1339 insertions(+) create mode 100644 doc/guides/cryptodevs/features/uadk.ini create mode 100644 doc/guides/cryptodevs/uadk.rst create mode 100644 drivers/crypto/uadk/meson.build create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd.c create mode 100644 drivers/crypto/uadk/version.map -- 2.38.1

1 6

[PATCH] bus/vdev: vdev_cleanup checks dev->device.driver
by Zhangfei Gao 20 Oct '22

20 Oct '22

The vdev_probe calls driver->probe, which may fail and dev->device.driver will still be NULL. In vdev_cleanup, drv = container_of(dev->device.driver) returns !NULL, then drv->remove will trigger Segmentation fault. Fix it by checking dev->device.driver first. Log: Thread 1 "dpdk-test" received signal SIGSEGV, Segmentation fault. 0x00000000012c484d in vdev_cleanup () Signed-off-by: Zhangfei Gao <zhangfei.gao(a)linaro.org> --- drivers/bus/vdev/vdev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c index f5b43f1930..fbdaf68380 100644 --- a/drivers/bus/vdev/vdev.c +++ b/drivers/bus/vdev/vdev.c @@ -577,6 +577,9 @@ vdev_cleanup(void) const struct rte_vdev_driver *drv; int ret = 0; + if (dev->device.driver == NULL) + continue; + drv = container_of(dev->device.driver, const struct rte_vdev_driver, driver); if (drv == NULL || drv->remove == NULL) -- 2.36.1

2 6

crypto/uadk: introduce uadk crypto driver
by Akhil Goyal 20 Oct '22

20 Oct '22

Hi everyone, We have a new crypto PMD submitted on ML (http://patches.dpdk.org/project/dpdk/cover/20221008083747.6559-1-zhangfei.g…) This PMD is dependent on an external library which needs to be cross compiled for ARM on x86. It mandatorily need "numactl" also cross-compiled and instead of using pkg-config of libnuma, it need the library and headers to be copied manually to aarch toolchain. And if that is also done, it is not generating pkg-config which DPDK can use to compile the PMD. So the question is whether we can accept the PMD without pkg-config and along with above dependency? Regards, Akhil

3 9

[PATCH resend v3 0/6] crypto/uadk: introduce uadk crypto driver
by Zhangfei Gao 14 Oct '22

14 Oct '22

Introduce a new crypto PMD for hardware accelerators based on UADK [1]. UADK is a framework for user applications to access hardware accelerators. UADK relies on IOMMU SVA (Shared Virtual Address) feature, which share the same page table between IOMMU and MMU. Thereby user application can directly use virtual address for device dma, which enhances the performance as well as easy usability. [1] https://github.com/Linaro/uadk Test: sudo dpdk-test --vdev=crypto_uadk (--log-level=6) RTE>>cryptodev_uadk_autotest RTE>>quit resend: Rebase on next/for-main, which just merged series "cryptodev: rework session framework". update in v3: Split patches according to Akhil's suggestions Please split the patches as below. 1. introduce driver - create files with meson.build and with probe/remove and device ops defined but not implemented. You do not need to write empty functions. Add basic documentation also which defines what the driver is. You can explain the build dependency here. 2. define queue structs and setup/remove APIs 3. Add data path 4. implement cipher op. Add capabilities and documentation of what is supported in each of the patch. Add feature flags etc. 5. implement auth, add capabilities and documentation 6. test app changes. Update in v2: Change uadk_supported_platform to uadk_crypto_version, which matches better than platform. enum uadk_crypto_version { UADK_CRYPTO_V2, UADK_CRYPTO_V3, }; Update in v1, compared with rfc Suggested from Akhil Goyal <gakhil(a)marvell.com> Only consider crypto PMD first Split patch into small (individually compiled) patches. Update MAINTAINERS and doc/guides/cryptodevs/features/uadk.ini Zhangfei Gao (6): crypto/uadk: introduce uadk crypto driver crypto/uadk: support basic operations crypto/uadk: support enqueue/dequeue operations crypto/uadk: support cipher algorithms crypto/uadk: support auth algorithms test/crypto: add cryptodev_uadk_autotest MAINTAINERS | 6 + app/test/test_cryptodev.c | 7 + app/test/test_cryptodev.h | 1 + doc/guides/cryptodevs/features/uadk.ini | 55 ++ doc/guides/cryptodevs/index.rst | 1 + doc/guides/cryptodevs/uadk.rst | 74 ++ drivers/crypto/meson.build | 1 + drivers/crypto/uadk/meson.build | 36 + drivers/crypto/uadk/uadk_crypto_pmd.c | 1145 +++++++++++++++++++++++ drivers/crypto/uadk/version.map | 3 + 10 files changed, 1329 insertions(+) create mode 100644 doc/guides/cryptodevs/features/uadk.ini create mode 100644 doc/guides/cryptodevs/uadk.rst create mode 100644 drivers/crypto/uadk/meson.build create mode 100644 drivers/crypto/uadk/uadk_crypto_pmd.c create mode 100644 drivers/crypto/uadk/version.map -- 2.36.1

2 14

Fw:Re: query about glibc 2.35 hugetlb
by Zhangfei Gao 12 Oct '22

12 Oct '22

  ------------------ Original ------------------ From: "Adhemerval Zanella Netto" <adhemerval.zanella(a)linaro.org>; Date: Mon, Oct 10, 2022 08:11 PM To: "Zhangfei Gao"<zhangfei.gao(a)linaro.org>; Subject: Re: query about glibc 2.35 hugetlb On 10/10/22 04:54, Zhangfei Gao wrote: > Hi, Adhemerval > Hi Zhangfei Gao, > We are using libhugetlbfs feature to concur the tlb miss issue. > LD_PRELOAD=/usr/lib/aarch64-linux-gnu/libhugetlbfs.so HUGETLB_MORECORE=yes app > > Happened to find morecore will be deprecated in glibc, 2.32+ The bug reports is incorrect, it was deprecated in glibc 2.34 and I have implemented glibc.malloc.hugetlb for 2.35.  So only glibc 2.34 does not have a way to explicit back up malloc allocation with hugetbl without using a full allocation (such as jemalloc or tcmalloc). > https://github.com/libhugetlbfs/libhugetlbfs/issues/52 > > Thanks for your patch adding  glibc.malloc.hugetlb. > But  still don't know how to use this feature. > >> If using glibc 2.35, do we still need libhugetlbfs.so? It will depends whether your application need to use HUGETLB_ELFMAP and/or HUGETLB_SHM since it is not implemented on glibc.  The HUGETLB_ELFMAP requires a lot of hacks and kernel/toolchain have worked to make THP to work better with text and data segments, and I think it is unlikely that we will support on glibc anytime soon (it will most likely require changes in the ELF gnu extension to explicit use huge pages). For HUGETLB_SHM it should be easy to adapt the code to align to page size and add SHM_HUGETLB. I think it might be doable to add support on glibc with an extra tunable as well to avoid code changes in the application.  I still prefer to adapt the the application itself because libhugetlbfs subtly change shmget semantic under the hood (by changing memory alignment and segment). >> Or just run "GLIBC_TUNABLES=glibc.malloc.hugetlb=2 app"? Based on the command line you pasted, it should be only that.  It will cover all memory allocation done by malloc. > > I am still in checking how to upgrading to glibc 2.35 in system. Carlos O'Donnel from RH was thinking about backporting to old releases if

1 0

UADK周例会
by openEuler conference 11 Oct '22

11 Oct '22

您好！ sig-AccLib SIG 邀请您参加 2022-10-12 11:00 召开的Zoom会议会议主题：UADK周例会会议内容： zoom会议，ID: 91879279131 固定的会议链接：https://linaro-org.zoom.us/j/91879279131 1.uadk版本节奏 2.交叉编译改进 3.自由讨论会议链接：https://us06web.zoom.us/j/85494335620?pwd=Mm81N2xRWC9DbytUdFhpTW9mR2N1UT09 会议纪要：https://etherpad.openeuler.org/p/sig-AccLib-meetings 温馨提醒：建议接入会议后修改参会人的姓名，也可以使用您在gitee.com的ID 更多资讯尽在：https://openeuler.org/zh/ Hello! openEuler sig-AccLib SIG invites you to attend the Zoom conference will be held at 2022-10-12 11:00, The subject of the conference is UADK周例会, Summary: zoom会议，ID: 91879279131 固定的会议链接：https://linaro-org.zoom.us/j/91879279131 1.uadk版本节奏 2.交叉编译改进 3.自由讨论 You can join the meeting at https://us06web.zoom.us/j/85494335620?pwd=Mm81N2xRWC9DbytUdFhpTW9mR2N1UT09. Add topics at https://etherpad.openeuler.org/p/sig-AccLib-meetings. Note: You are advised to change the participant name after joining the conference or use your ID at gitee.com. More information: https://openeuler.org/en/

1 0

82694713254
by a5d22 11 Oct '22

11 Oct '22

1 0

[PATCH] drv/qm: fix spelling mistake
by Weili Qian 09 Oct '22

09 Oct '22

There is a spelling mistakes in branch name, fix it. Signed-off-by: Weili Qian <qianweili(a)huawei.com> --- drv/hisi_qm_udrv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drv/hisi_qm_udrv.c b/drv/hisi_qm_udrv.c index 2497f49..a15bcc6 100644 --- a/drv/hisi_qm_udrv.c +++ b/drv/hisi_qm_udrv.c @@ -352,12 +352,12 @@ static int hisi_qm_setup_info(struct hisi_qp *qp, struct hisi_qm_priv *config) ret = pthread_spin_init(&q_info->sd_lock, PTHREAD_PROCESS_SHARED); if (ret) { WD_DEV_ERR(qp->h_ctx, "failed to init qinfo sd_lock!\n"); - goto err_destory_lock; + goto err_destroy_lock; } return 0; -err_destory_lock: +err_destroy_lock: pthread_spin_destroy(&q_info->rv_lock); err_out: hisi_qm_unset_region(qp->h_ctx, q_info); -- 2.33.0

1 0

[PATCH] uadk: v1: gets queue configuration from acc driver
by Weili Qian 09 Oct '22

09 Oct '22

Get the queue depth and submission queue element size from kernel acc driver. Signed-off-by: Weili Qian <qianweili(a)huawei.com> --- v1/drv/hisi_qm_udrv.c | 73 ++++++++++++++++++++++++++++++++----------- v1/drv/hisi_qm_udrv.h | 12 ++++++- 2 files changed, 65 insertions(+), 20 deletions(-) diff --git a/v1/drv/hisi_qm_udrv.c b/v1/drv/hisi_qm_udrv.c index 54aa016..bf950da 100644 --- a/v1/drv/hisi_qm_udrv.c +++ b/v1/drv/hisi_qm_udrv.c @@ -453,15 +453,56 @@ static int qm_set_db_info(struct q_info *qinfo) return 0; } -static int qm_set_queue_info(struct wd_queue *q) +static int qm_init_queue_info(struct wd_queue *q) { struct wcrypto_paras *priv = &q->capa.priv; struct q_info *qinfo = q->qinfo; struct qm_queue_info *info = qinfo->priv; + struct hisi_qp_info qp_info; struct hisi_qp_ctx qp_ctx; + int ret; + + info->sq_tail_index = 0; + info->cq_head_index = 0; + info->cqc_phase = 1; + info->used = 0; + info->is_poll = priv->is_poll; + qp_ctx.qc_type = priv->direction; + qp_ctx.id = 0; + ret = ioctl(qinfo->fd, WD_UACCE_CMD_QM_SET_QP_CTX, &qp_ctx); + if (ret < 0) { + WD_ERR("failed to set qp type!\n"); + return ret; + } + info->sqn = qp_ctx.id; + + ret = ioctl(qinfo->fd, WD_UACCE_CMD_QM_SET_QP_INFO, &qp_info); + if (ret < 0) { + WD_ERR("failed to get qp info, use default value!\n"); + + /* The default value of sqe_size has been set in qm_set_queue_alg_info. */ + info->sq_depth = QM_Q_DEPTH; + info->cq_depth = QM_Q_DEPTH; + } else { + info->sq_depth = qp_info.sq_depth; + info->cq_depth = qp_info.cq_depth; + info->sqe_size = qp_info.sqe_size; + } + + return 0; +} + +static int qm_set_queue_info(struct wd_queue *q) +{ + struct q_info *qinfo = q->qinfo; + struct qm_queue_info *info = qinfo->priv; size_t psize; int ret; + ret = qm_init_queue_info(q); + if (ret) + return ret; + ret = qm_set_queue_regions(q); if (ret) return -EINVAL; @@ -471,11 +512,11 @@ static int qm_set_queue_info(struct wd_queue *q) goto err_with_regions; } info->cq_base = (void *)((uintptr_t)info->sq_base + - info->sqe_size * QM_Q_DEPTH); + info->sqe_size * info->sq_depth); /* Protect the virtual address of CQ to avoid being over written */ psize = qinfo->qfrs_offset[WD_UACCE_QFRT_DUS] - - info->sqe_size * QM_Q_DEPTH; + info->sqe_size * info->sq_depth; ret = mprotect(info->cq_base, psize, PROT_READ); if (ret) { WD_ERR("cqe mprotect set err!\n"); @@ -491,19 +532,11 @@ static int qm_set_queue_info(struct wd_queue *q) if (ret) goto err_with_regions; - info->sq_tail_index = 0; - info->cq_head_index = 0; - info->cqc_phase = 1; - info->used = 0; - info->is_poll = priv->is_poll; - qp_ctx.qc_type = priv->direction; - qp_ctx.id = 0; - ret = ioctl(qinfo->fd, WD_UACCE_CMD_QM_SET_QP_CTX, &qp_ctx); - if (ret < 0) { - WD_ERR("hisi qm set qc_type fail, use default!\n"); + info->req_cache = calloc(info->sq_depth, sizeof(void *)); + if (!info->req_cache) { + ret = -WD_ENOMEM; goto err_with_regions; } - info->sqn = qp_ctx.id; return 0; @@ -545,8 +578,10 @@ err_with_priv: void qm_uninit_queue(struct wd_queue *q) { struct q_info *qinfo = q->qinfo; + struct qm_queue_info *info = qinfo->priv; qm_unset_queue_regions(q); + free(info->req_cache); free(qinfo->priv); qinfo->priv = NULL; } @@ -570,7 +605,7 @@ int qm_send(struct wd_queue *q, void **req, __u32 num) wd_spinlock(&info->sd_lock); if (unlikely(__atomic_load_n(&info->used, __ATOMIC_RELAXED) > - QM_Q_DEPTH - num - 1)) { + info->sq_depth - num - 1)) { wd_unspinlock(&info->sd_lock); WD_ERR("queue is full!\n"); return -WD_EBUSY; @@ -585,7 +620,7 @@ int qm_send(struct wd_queue *q, void **req, __u32 num) return -WD_EINVAL; } - if (info->sq_tail_index == QM_Q_DEPTH - 1) + if (info->sq_tail_index == info->sq_depth - 1) info->sq_tail_index = 0; else info->sq_tail_index++; @@ -615,7 +650,7 @@ void qm_rx_from_cache(struct qm_queue_info *info, void **resp, __u32 num) resp[i] = info->req_cache[idx]; info->req_cache[idx] = NULL; - if (idx == QM_Q_DEPTH - 1) { + if (idx == info->cq_depth - 1) { info->cqc_phase = !(info->cqc_phase); idx = 0; } else { @@ -666,7 +701,7 @@ int qm_recv(struct wd_queue *q, void **resp, __u32 num) mb(); /* make sure the data is all in memory before read */ sq_head = CQE_SQ_HEAD_INDEX(cqe); - if (unlikely(sq_head >= QM_Q_DEPTH)) { + if (unlikely(sq_head >= info->sq_depth)) { wd_unspinlock(&info->rc_lock); WD_ERR("CQE_SQ_HEAD_INDEX(%u) error\n", sq_head); return -WD_EIO; @@ -686,7 +721,7 @@ int qm_recv(struct wd_queue *q, void **resp, __u32 num) resp[i] = info->req_cache[info->cq_head_index]; info->req_cache[info->cq_head_index] = NULL; - if (info->cq_head_index == QM_Q_DEPTH - 1) { + if (info->cq_head_index == info->cq_depth - 1) { info->cqc_phase = !(info->cqc_phase); info->cq_head_index = 0; } else { diff --git a/v1/drv/hisi_qm_udrv.h b/v1/drv/hisi_qm_udrv.h index 0d40d86..cc1aa33 100644 --- a/v1/drv/hisi_qm_udrv.h +++ b/v1/drv/hisi_qm_udrv.h @@ -125,6 +125,13 @@ struct hisi_qp_ctx { __u16 qc_type; }; +struct hisi_qp_info { + __u32 sqe_size; + __u16 sq_depth; + __u16 cq_depth; + __u64 reserved; +}; + struct qm_queue_info; typedef int (*qm_sqe_fill)(void *msg, @@ -147,13 +154,15 @@ struct qm_queue_info { void *ds_rx_base; __u16 sq_tail_index; __u16 cq_head_index; + __u16 sq_depth; + __u16 cq_depth; __u16 sqn; __u16 resv; bool is_poll; int cqc_phase; int used; int sqe_size; - void *req_cache[QM_Q_DEPTH]; + void **req_cache; qm_sqe_fill sqe_fill[WCRYPTO_MAX_ALG]; qm_sqe_parse sqe_parse[WCRYPTO_MAX_ALG]; hisi_qm_sqe_fill_priv sqe_fill_priv; @@ -192,5 +201,6 @@ void qm_rx_from_cache(struct qm_queue_info *info, void **resp, __u32 num); #define HISI_QM_API_VER3_BASE "hisi_qm_v3" #define WD_UACCE_CMD_QM_SET_QP_CTX _IOWR('H', 10, struct hisi_qp_ctx) +#define WD_UACCE_CMD_QM_SET_QP_INFO _IOWR('H', 11, struct hisi_qp_info) #endif -- 2.33.0

1 0

[PATCH] drv/qm: gets queue info from acc driver
by Weili Qian 09 Oct '22

09 Oct '22

Get the queue depth and submission queue element size from kernel acc driver. Signed-off-by: Weili Qian <qianweili(a)huawei.com> --- drv/hisi_qm_udrv.c | 40 ++++++++++++++++++++++++++++++---------- include/hisi_qm_udrv.h | 2 ++ 2 files changed, 32 insertions(+), 10 deletions(-) diff --git a/drv/hisi_qm_udrv.c b/drv/hisi_qm_udrv.c index 93f2eb7..2497f49 100644 --- a/drv/hisi_qm_udrv.c +++ b/drv/hisi_qm_udrv.c @@ -25,6 +25,7 @@ #define VERSION_ID_SHIFT 9 #define UACCE_CMD_QM_SET_QP_CTX _IOWR('H', 10, struct hisi_qp_ctx) +#define UACCE_CMD_QM_SET_QP_INFO _IOWR('H', 11, struct hisi_qp_info) #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) /* the max sge num in one sgl */ @@ -62,6 +63,13 @@ struct hisi_qp_ctx { __u16 qc_type; }; +struct hisi_qp_info { + __u32 sqe_size; + __u16 sq_depth; + __u16 cq_depth; + __u64 reserved; +}; + struct hisi_sge { uintptr_t buff; void *page_ctrl; @@ -151,11 +159,11 @@ static void hisi_qm_fill_sqe(const void *sqe, struct hisi_qm_queue_info *info, void *sq_base = info->sq_base; int idx; - if (tail + num < QM_Q_DEPTH) { + if (tail + num < info->sq_depth) { memcpy((void *)((uintptr_t)sq_base + tail * sqe_size), sqe, sqe_size * num); } else { - idx = QM_Q_DEPTH - tail; + idx = info->sq_depth - tail; memcpy((void *)((uintptr_t)sq_base + tail * sqe_size), sqe, sqe_size * idx); memcpy(sq_base, (void *)((uintptr_t)sqe + sqe_size * idx), @@ -243,6 +251,7 @@ static int hisi_qm_setup_db(handle_t h_ctx, struct hisi_qm_queue_info *q_info) static int his_qm_set_qp_ctx(handle_t h_ctx, struct hisi_qm_priv *config, struct hisi_qm_queue_info *q_info) { + struct hisi_qp_info qp_cfg; struct hisi_qp_ctx qp_ctx; int ret; @@ -251,12 +260,24 @@ static int his_qm_set_qp_ctx(handle_t h_ctx, struct hisi_qm_priv *config, q_info->qc_type = qp_ctx.qc_type; ret = wd_ctx_set_io_cmd(h_ctx, UACCE_CMD_QM_SET_QP_CTX, &qp_ctx); if (ret < 0) { - WD_DEV_ERR(h_ctx, "failed to set qc_type, use default value!\n"); + WD_DEV_ERR(h_ctx, "failed to set qc_type!\n"); return ret; } - q_info->sqn = qp_ctx.id; + ret = wd_ctx_set_io_cmd(h_ctx, UACCE_CMD_QM_SET_QP_INFO, &qp_cfg); + if (ret < 0) { + WD_DEV_ERR(h_ctx, "set qp info failed, use default value!\n"); + + q_info->sq_depth = QM_Q_DEPTH; + q_info->cq_depth = QM_Q_DEPTH; + q_info->sqe_size = config->sqe_size; + } else { + q_info->sq_depth = qp_cfg.sq_depth; + q_info->cq_depth = qp_cfg.cq_depth; + q_info->sqe_size = qp_cfg.sqe_size; + } + return 0; } @@ -315,9 +336,8 @@ static int hisi_qm_setup_info(struct hisi_qp *qp, struct hisi_qm_priv *config) q_info->qp_mode = config->qp_mode; q_info->epoll_en = config->epoll_en; q_info->idx = config->idx; - q_info->sqe_size = config->sqe_size; q_info->cqc_phase = 1; - q_info->cq_base = q_info->sq_base + config->sqe_size * QM_Q_DEPTH; + q_info->cq_base = q_info->sq_base + (__u64)config->sqe_size * q_info->sq_depth; /* The last 32 bits of DUS show device or qp statuses */ q_info->ds_tx_base = q_info->sq_base + q_info->region_size[UACCE_QFRT_DUS] - sizeof(uint32_t); @@ -356,7 +376,7 @@ static void hisi_qm_clear_info(struct hisi_qp *qp) static int get_free_num(struct hisi_qm_queue_info *q_info) { /* The device should reserve one buffer. */ - return (QM_Q_DEPTH - 1) - + return (q_info->sq_depth - 1) - __atomic_load_n(&q_info->used_num, __ATOMIC_RELAXED); } @@ -463,7 +483,7 @@ int hisi_qm_send(handle_t h_qp, const void *req, __u16 expect, __u16 *count) tail = q_info->sq_tail_index; hisi_qm_fill_sqe(req, q_info, tail, send_num); - tail = (tail + send_num) % QM_Q_DEPTH; + tail = (tail + send_num) % q_info->sq_depth; q_info->db(q_info, QM_DBELL_CMD_SQ, tail, 0); q_info->sq_tail_index = tail; @@ -488,7 +508,7 @@ static int hisi_qm_recv_single(struct hisi_qm_queue_info *q_info, void *resp) if (q_info->cqc_phase == CQE_PHASE(cqe)) { j = CQE_SQ_HEAD_INDEX(cqe); - if (unlikely(j >= QM_Q_DEPTH)) { + if (unlikely(j >= q_info->sq_depth)) { pthread_spin_unlock(&q_info->rv_lock); WD_DEV_ERR(qp->h_ctx, "CQE_SQ_HEAD_INDEX(%u) error!\n", j); return -WD_EIO; @@ -500,7 +520,7 @@ static int hisi_qm_recv_single(struct hisi_qm_queue_info *q_info, void *resp) return -WD_EAGAIN; } - if (i == QM_Q_DEPTH - 1) { + if (i == q_info->cq_depth - 1) { q_info->cqc_phase = !(q_info->cqc_phase); i = 0; } else { diff --git a/include/hisi_qm_udrv.h b/include/hisi_qm_udrv.h index 22dedf3..dda320d 100644 --- a/include/hisi_qm_udrv.h +++ b/include/hisi_qm_udrv.h @@ -68,6 +68,8 @@ struct hisi_qm_queue_info { __u8 qp_mode; __u16 sq_tail_index; __u16 cq_head_index; + __u16 sq_depth; + __u16 cq_depth; __u16 sqn; __u16 qc_type; __u16 used_num; -- 2.33.0

1 0