Failed to run DOCA l2_reflector on the host side

Infrastructure & Networking DOCA Enterprise Networking
,
1

Hi,

I am trying to run the DOCA 2.2 example application, l2_reflector. I’ve noticed that when I invoke the DOCA l2_reflector from the DPU ARM side, it runs successfully. However, when I try to invoke it from the Host x86 CPU side, I am encountering the following errors:

  • flexio_create_prm_thread 395 - Failed to create PRM thread object. Error number is 121.
  • create_thread 168 - Failed to create thread
  • flexio_event_handler_create 255 - Failed to create thread
  • [05:17:48:564784][DOCA][ERR][L2_REFLECTOR::CORE:122]: Could not create event handler (-1)

My host system is running Ubuntu 22.04 with DOCA 2.2. I’ve also confirmed that two ib devices, mlx5_0 and mlx5_1, are detectable on the host x86 CPU side.

Any assistance in resolving these issues would be greatly appreciated.

Thank you.

2

hi, i also meet same question when i try to run the doca_dpa sample:dpa_kernel_lanuch. Do you have a solution now?

3

flexio_create_prm_thread 395 - Failed to create PRM thread object. Error number is 121.
create_thread 168 - Failed to create thread
process_call 385 - Failed to create thread
internal_msg_stream_create 695 - Failed to call msg stream config dev handler

4

Info: Welcome to DOCA Programable Congestion Control (PCC) application
Info: Starting DOCA PCC
flexio_create_prm_thread 406 - Failed to create PRM thread object. Status is 0x5, syndrome 0x901242.
create_thread 163 - Failed to create thread
process_call 454 - Failed to create thread
internal_msg_stream_create 786 - Failed to call msg stream config dev handler

1 Like
5

hi, i also meet same question. Do you have a solution now?

6

Hi, I meet the same question? Do you have a solution now?

7

I recently discovered that using DOCA 2.9.0 was causing some errors. After switching to DOCA 2.8.0, these issues were resolved.

8

We ran into a similar problem in DOCA 3.1:

Failed to create PRM process. Status is 0x5, syndrome 0xb398a0.

The following is our solution. Please let us know if there should be any corrections:

There are 16 cores/254 EUs on the BF-3. In DPU mode, all EUs are allocated to
the ARM by default. These resources must be manually partitioned before they
can be used on the host.

To partition the host PFs with half the DPA EUs

$ sudo /opt/mellanox/doca/tools/dpaeumgmt create --dpa_device mlx5_0 --vhca_list 0,1 --range_eus 0-127 --max_num_eu_group 7

vHCA IDs 0x0 and 0x1 correspond to the two PFs on the host-side. This creates
a partition with 128 EUs, and up to 7 groups assigned to the host-side PFs.

Remaining vHCA IDs (e.g. VFs) can be verified with

$ sudo /opt/mellanox/doca/tools/dpaeumgmt info vhca --dpa_device mlx5_0

The DPA device can be any RDMA name on the same device that all refers back to
the same DPU. (e.g. Listing all vHCAs on mlx5_0 may also include entries from
mlx5_1 for a dual-port NIC)

Partitions are cleared on DPU reboot, use dpa-resource-mgmt to create a
restorable config.

To remove the partition

$ sudo /opt/mellanox/doca/tools/dpaeumgmt query --dpa_device mlx5_0
$ sudo /opt/mellanox/doca/tools/dpaeumgmt destroy --dpa_device mlx5_0 --id_partition <id>
1 Like
9

my doca version is 2.9.3. When I use the command in DPU arm:

sudo /opt/mellanox/doca/tools/dpaeumgmt partition create --dpa_device mlx5_0 --vhca_list 0,1 --range_eus 0-127 --max_num_eu_group 7

it run in host successfully!