# Large number of DPIOs needed for DPDK test **URL:** \ **Category:** NXP LX2160\ **Created:** [February 28, 2022, 2:19pm UTC](https://community.solid-run.com/t/large-number-of-dpios-needed-for-dpdk-test/251 "2022-02-28T14:19:48Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![embeddedDeveloper](https://avatars.discourse-cdn.com/v4/letter/e/c4cdca/32.png) [@embeddedDeveloper](https://community.solid-run.com/u/embeddedDeveloper)\ **Post date:** [February 28, 2022, 2:19pm UTC](https://community.solid-run.com/t/large-number-of-dpios-needed-for-dpdk-test/251/1 "2022-02-28T14:19:48Z")
I am trying to reproduce tests I did on an NXP RDB (rev1 with older software) on the HoneyComb. I’ve been able to reproduce the issue I’m seeing on the HoneyComb with a simple test case. I used the SolidRun git repo with the following change (as mentioned in the Quick Start Guide): I added " isolcpus=1-15 iommu.passthrough=1" to extlinux.conf. When I run the list of commands at the end of this post, I see the following when I launch the testpmd application: fslmc: No software portal resource left fslmc: Error in software portal allocation dpaa2\_net: Failure in affining portal fslmc: No software portal resource left … This appears to be caused by the number of DPIOs: with 5 the test works, with 4 it does not. I don’t understand why 5 DPIOs would be needed in this case. The NXP RDB works fine with 4 DPIOs. # List of commands: export DPCI\_COUNT=0 export DPIO\_COUNT=4 # Experimentally I found 5 does work export DPBP\_COUNT=1 export DPCON\_COUNT=3 export DPSECI\_COUNT=0 export MAX\_QOS=1 export MAX\_QUEUES=1 export MAX\_CGS=1 export MAX\_TCS=1 export DPCON\_PRIORITIES=1 export DPMAC=dpmac.10 export DPNI=dpni.1 export CTRL\_ETH1=eth1 export CTRL\_ETH2=eth2 export TEST\_PMD=/usr/bin/dpdk-testpmd export BEFORE\_MAC=00:00:00:00:04:02 export MY\_MAC=00:00:00:00:04:03 export OTH\_MAC=00:00:00:00:05:03 cd /usr/bin ./dynamic\_dpl.sh dpni -b ${BEFORE\_MAC} ls-addsw -o=DPSW\_OPT\_CTRL\_IF\_DIS ${DPNI} ${DPMAC} ip link add name br type bridge ip link set dev br up ls /sys/bus/fsl-mc/drivers/fsl\_mc\_dprc/dprc.1/dpsw.0/net/ ip link set dev ${CTRL\_ETH1} down ip link set dev ${CTRL\_ETH1} address 00:00:00:00:00:01 up ip link set dev ${CTRL\_ETH1} master br ip link set dev ${CTRL\_ETH2} down ip link set dev ${CTRL\_ETH2} address 00:00:00:00:00:02 up ip link set dev ${CTRL\_ETH2} master br export DPRC=dprc.2 restool dpni info ${DPNI} ${TEST\_PMD} -c 0x3 -n 1 – --eth-peer=0,${OTH\_MAC} --txd=1500 --txpkts=1500 --tx-first --auto-start --forward-mode=mac --stats-period=10 ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [March 1, 2022, 12:26pm UTC](https://community.solid-run.com/t/large-number-of-dpios-needed-for-dpdk-test/251/2 "2022-03-01T12:26:43Z")
Most likely this is due to the memory available for the network packet processor / management complex. However it could be something as simple as the firmware running on the mc-bin complex. Are you running the same BSP versions on both the RDB and the HC? ---
**Author:** ![embeddedDeveloper](https://avatars.discourse-cdn.com/v4/letter/e/c4cdca/32.png) [@embeddedDeveloper](https://community.solid-run.com/u/embeddedDeveloper)\ **Post date:** [March 1, 2022, 12:50pm UTC](https://community.solid-run.com/t/large-number-of-dpios-needed-for-dpdk-test/251/3 "2022-03-01T12:50:39Z")
For the NXP RDB: MC=10.29.0, restool=la1224rdb-early-access-bsp0.6 For the HoneyComb: MC=10.31.1, restool=v2.3 (commit lf-5.10.52-2.1.0) Unfortunately with the NXP RDB, we have a rev 1 board, which makes it difficult to upgrade since they dropped support for the Rev 1s as of LSDK 20.12 and onwards. I could revert the Honey comb to 20.04 or further back to see if there is a point that it works for the test in question. For the NXP board, I’ve had several MC/restool issues with the NXP RDB, where I needed to upgrade to the latest version to fix issues. ---
**Author:** ![embeddedDeveloper](https://avatars.discourse-cdn.com/v4/letter/e/c4cdca/32.png) [@embeddedDeveloper](https://community.solid-run.com/u/embeddedDeveloper)\ **Post date:** [March 1, 2022, 1:01pm UTC](https://community.solid-run.com/t/large-number-of-dpios-needed-for-dpdk-test/251/4 "2022-03-01T13:01:28Z")
One other thing - I’ve noticed that restool reports an error when dynamic\_dpl.sh is used. It suggests that something isn’t quite right with the current version. When I do a “./dynamic\_dpl.sh dpmac.10” (and I don’t override any of the environment variables for the script), I see: > restool dpni info dpni.1 > dpni version: 8.1 > dpni id: 1 > plugged state: plugged > endpoint state: 0 > endpoint: dpmac.10, link is down > link status: 0 - down > mac address: 00:00:00:00:00:10 > max frame length: 1536 > dpni\_attr.options value is: 0x80000310 > Unrecognized options found… \<\<\< problem… I suspect this is something to do with high performance buffers (used by default). If I don’t use the high performance buffers the unrecognized option goes away. ---
**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\ **Post date:** [March 2, 2022, 5:53am UTC](https://community.solid-run.com/t/large-number-of-dpios-needed-for-dpdk-test/251/5 "2022-03-02T05:53:45Z")
You are using dynamic\_dpl.sh from NXP’s dpdk-extras repository? That repo hasn’t been updated in quite a long time. My guess is that there is now an incompatibility between those scripts and the restool / mcbin firmware versions. I will try to carve out some time and test your example cases. ---
**Author:** ![embeddedDeveloper](https://avatars.discourse-cdn.com/v4/letter/e/c4cdca/32.png) [@embeddedDeveloper](https://community.solid-run.com/u/embeddedDeveloper)\ **Post date:** [March 2, 2022, 12:37pm UTC](https://community.solid-run.com/t/large-number-of-dpios-needed-for-dpdk-test/251/6 "2022-03-02T12:37:30Z")
Sounds right - I’m using the script from dpdk/nxp/dpaa2/dynamic\_dpl.sh. Thanks for looking into this.