I got tnsr-v20.10.1-2 working within virtualization with Intel XXV710-DA2. This still faced some challenges:
upgrading firmware to 7.30 as suggested to match tnsr's DPDK version
here wouldn't work from within virtualization. I had to put the card in a bare hardware machine or else ./nvmupdate64e found the card but showed "Access Error" on the RHS of the card table.
After downloading Intel's firmware tool, a.k.a. "NVM", for old revision 7.30, the tool refused to touch the card at first, "no update available" while showing version "6.128(6.80)." The documented versions of intel i40e firmware seem to correspond to the "hex" version in parenthesis shown in nvmupdate64e, yet as is their typical style they needlessly show both. stfw showed there are a lot of OEM cards that Intel tries to force you to the OEM's payware service plans for updates, but closely reading
Intel's docs 4.0, 'ethtool -i <device>' reveals the "EtrackID" as the second field of "firmware-revision", a hex number like 0x8000xxxx. Adding this number to the REPLACES: field of nvmupdate.cfg of a similar card (good luck!) will force the update to go through anyway.
Intel's MAC is picky about SFP+ modules. A module with Cisco srom worked. A Dell module that works fine in ConnectX-3 En didn't work. Updated 7.30 firmware printed a dmesg warning about disliking the module on each insertion, but older 6.80 firmware silently showed link down, IIRC.
For me, my bias/impression that the Intel parts would be overcomplicated and buggy wrt Mellanox was confirmed. There could be something subtly wrong with my virtualization config, or something I can't even think of, blocking the ConnectX-3 and ConnectX-5 from working, but partially arguing against that at least I can confirm Intel XXV710-DA2 works with TNSR in a controlled situation where Mellanox parts don't.