Skip to content

ZUC, SNOW3G and KASUMI Integration

Jump to bottom
Pablo de Lara edited this page Jan 13, 2023 · 6 revisions

ZUC, SNOW3G and KASUMI have been added to the library for release version 0.53

The three algorithms are supported in DPDK and since DPDK 20.02 intel-ipsec-mb starts provide implementation for them vs previously used LIBSSO libraries.

intel-ipsec-mb also provides multiple algorithm implementations for GCM and AESNI DPDK polled mode drivers.

Further development and maintenance of ZUC, SNOW3G and KASUMI implementations will only take place within intel-ipsec-mb library.

SNOW3G, ZUC and KASUMI with Library Version 1.1+ and DPDK 21.11+

From intel-ipsec-mb version 1.1 and DPDK version 21.11, using the DPDK AESNI MB PMD is recommended to get maximum performance (instead of ZUC, SNOW3G and KASUMI PMDs). The AESNI MB PMD uses the intel-ipsec-mb job API and supports wireless algorithm mixing (e.g. SNOW3G-UEA2 cipher algorithm + ZUC-EIA3 hash algorithm).

In order to use this PMD on any DPDK application, use the following command line:

./dpdk_app --vdev="crypto_aesni_mb1" [Other EAL parameters] -- [Application specific parameters]

For more information about using the PMD, go to: https://doc.dpdk.org/guides/cryptodevs/aesni_mb.html

Issues with DPDK 21.11 and prior releases

DPDK 21.11 and prior releases might generate wrong authentication tags due to a wrong offset calculation. The following DPDK versions are affected:

  • DPDK version <= 21.11

The following DPDK versions are OK:

  • DPDK stable version >= 21.11.1
  • DPDK version >= 22.03

If DPDK 21.11 needs to be used, the following two options are recommended:

Multi-core Scaling with DPDK Crypto Scheduler

In order to facilitate scaling, the DPDK crypto scheduler can be used to encrypt/authenticate on multiple cores simultaneously. The benefit of using the scheduler is fixed cost of crypto from the application perspective and ability to scale the throughput.

The following command line creates 4 AESNI-MB PMD instances and 1 scheduler PMD instance which distributes the crypto operations among the different CPU cores and runs the DPDK crypto performance application to benchmark SNOW3G-UEA2 + SNOW3G-UIA2 on 700B packets, using cores 6-9:

DPDK_dir/build/app/dpdk-test-crypto-perf -l 4-9 --vdev=crypto_aesni_mb1,name=aesni_mb1 --vdev=crypto_aesni_mb2,name=aesni_mb2 --vdev=crypto_aesni_mb3,name=aesni_mb3 --vdev=crypto_aesni_mb4,name=aesni_mb4 --vdev="crypto_scheduler,ordering=enable,mode=multi-core,worker=aesni_mb1,worker=aesni_mb2,worker=aesni_mb3,worker=aesni_mb4,corelist=6;7;8;9" -- --devtype=crypto_scheduler --optype=cipher-then-auth --cipher-algo=snow3g-uea2 --cipher-key-sz 16 --cipher-iv-sz 16 --auth-algo snow3g-uia2 --auth-key-sz 16 --auth-iv-sz 16 --digest-sz 4 --buffer-sz 700 --total-ops 10000000 --auth-op generate --burst-sz 32 –silent

For more information, go to: https://doc.dpdk.org/guides/cryptodevs/scheduler.html

Q: Does DPDK 20.02 use intel-ipsec-mb to provide ZUC, KASUMI and SNOW3G?

A: Yes, it does. All subsequent DPDK release versions will do the same.

Q: What if I use DPDK 19.11? Can I use intel-ipsec-mb to provide SNOW3G, ZUC and KASUMI?

A: Yes, DPDK 19.11 SNOW3G, ZUC and KASUMI poll mode drivers can be patched to use intel-ipsec-mb. Make sure to apply the following patches in this order to avoid extra conflicts.

Q: What if I use DPDK 18.11? Can I use intel-ipsec-mb to provide SNOW3G and ZUC?

A: Yes, DPDK 18.11 SNOW3G, ZUC and KASUMI poll mode drivers can be patched to use intel-ipsec-mb. Make sure to apply the following patches in this order to avoid extra conflicts.

In addition, there are two extra patches to support version 0.53 in AESNI MB/GCM PMDs, supporting other TLS algorithms:

Q: What PMD to use for ZUC and SNOW3G with intel-ipsec-mb v1.1 and DPDK 21.11?

A: AESNI PMD provides better performance in this case. Consolidation of ZUC, SNOW3G and KASUMI PMDs into AESNI PMD is in progress.

Q: When one would use DPDK crypto scheduler?

A: It may be beneficial to use the crypto scheduler when

  • application was architected to work with a hardware accelerator (asynchronous mode of operation) and it assumes "fixed" cost of crypto offload
  • there is no core scaling capability in the application or it has some restrictions Note: number of cores dedicated for crypto operations can be tuned for given application/algorithm
  • More about DPDK crypto scheduler
Clone this wiki locally