Hi Ben, Returning to this issue, last discussed in June.
> > Thanks, now I tried it (the Patchset 2 variant) but it seems to > > behave like before, the delay is sitll happening. > > Hmm thanks ☹ > Can you try to export "MLX5_SHUT_UP_BF=1" in your environment before > starting VPP (ie, VPP environment must contain this)? This should > disable the "BlueFlame" mechanism in Mellanox NIC. Otherwise I'll > need to take a deeper look. Unfortunately that did not help, it seemed to behave the same also with "MLX5_SHUT_UP_BF=1" set. We are still having this problem now, with the current master branch. Like before, the behavior seems to be that when 2 packets are to be sent, only the first one gets sent directly, the second packet gets delayed. I have a test case now where the delay is more than 3 seconds. It seems the delay lasts until something else is to be sent, then the old packet gets sent also. So nothing gets lost, just delayed. But things can anyway fail, for example some ping tests fail because they time out. I have looked a bit more at it and tried to understand what happens, but I did not get much wiser, still just seems to me like VPP rings the "doorbell" and expects the packets to be sent, but somehow only one packet is sent and the other is delayed. Am I right to assume that the "doorbell" action is the last thing VPP is doing that we can check in the VPP source code itself, then we would need to go poke around inside the underlying rdma-core driver to see what is happening? Can you help more with this? Best regards, Elias
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18130): https://lists.fd.io/g/vpp-dev/message/18130 Mute This Topic: https://lists.fd.io/mt/75120690/21656 Mute #mellanox:https://lists.fd.io/g/vpp-dev/mutehashtag/mellanox Mute #rdma:https://lists.fd.io/g/vpp-dev/mutehashtag/rdma Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
