Could you clarify additional details of the issue, please?
What are the secondary and primary processes? Is it two processes over the PF/VF or it is one on PF and the second on VF?
What is the application flow?
What kind of multicast address?
What is the way to reproduce the issue?
Is it happens on 32-bit/64-bit or just 64-bit only?
Does the issue happens with the latest 4.0-2 version of MOFED and DPDK 16.11.2_3 and latest 16.19.1200 firmware?
The primary/secondary processes use the same interface.
Secondary process(es) are used for transmit. The primary process is used for transmit and receive.
The issue is reproducible with any multicast/broadcast mac address.
The issue happens w/ both 32-bit and 64-bit applications.
We are using ConnectX-3 and ConnectX-4 latest firmware 2.40.5030, 12_18_2000 as recommended in Mellanox DPDK release notes.
We don't have a ConnectX-5 (16.19.1200).
We are currently still using 4.0-220.127.116.11 kernel drivers as mentioned in original post which were latest drivers at the time 3/16.
It looks like 4.0-2 was only just released at end of march and hasn't even been pushed to your github repo yet.
I have attached a sample app which reproduces issue with broadcast MAC FF:FF:FF:FF:FF:FF.
Launch two instances of the application to reproduce the issue.
The first instance is launched as primary and sends a packet and then continuously reads the rx ring.
./build/app/mlx-mcast-test --proc-type primary -c 0x1
The second process is launched as secondary and sends a packet and exits.
./build/app/mlx-mcast-test --proc-type secondary -c 0x2
All packets which are transmitted and received are printed out.
The multicast issue can be observed when the secondary process sends a packet and the primary process receives it.
mlx-mcast-test.tgz 3.6 KB