Is any Azure instance type still using Mellanox connectx-3?

Question

Hi,

The Mellanox connectx-3 has been end of life. The newest Mellanox OFED package has removed mlx4 shared library files that are used by connectx-3. We are considering removing the connectx-3 support on our application in order to upgrade to the latest OFED version, but that might cause issue if the Azure VM instance is still having the connectx-3. How can I confirm whether connectx-3 is still been used by Azure VM instance or not? If yes, what is the Azure instance type list that still have connectx-3?

Thanks,

Lin

Answer 1

Hi Karishma,

Thanks a lot for helping with this topic. Your reply reflects what I found when I was searching the term of “connectx” on the portal before I posted the question. But it doesn’t provide the information we are looking for.  

 

The article “https://learn.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-powershell” is general tutorial for creating accelerated net that happens to use connectx-3 as an example. The connect-3 is mentioned on this article is likely that connect-3 is the early nic that support accelerated net.  The rest contents related to the accelerated networking are what we already know. Our application is already able to detect and work on connect-3,4,5.

 

What we want to know is whether connectx-3 has been end of live on Azure infrastructure? If yes, then we can safely drop the connectx-3 support on our application and upgrade to the newest Mellanox OFED version. If not, will there be a plan to put the connect-3 to EOF, and which instance types are still using the connect-3? With this info, we can add those instance types to the unsupported list for the newer version of our application. As you have mentioned that no documents show what instance types are still using connect-3,  Is it possible to get answer for these questions from the relevant development team?

Best regards,

Lin

Answer 2

Hi Lin Huang , Thanks for posting your query on Microsoft Q&A.

The Azure docs https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-powershell talks about the use of ConnectX-3 Ethernet adapter for Windows Server 2016 VM (Standard_DS4_v2).
Unfortunately, I couldn't find any document for the list of the Azure VM instance type that still have Connectx-3.
However, if you use Accelerated Networking, here is some information on how Mellanox drivers are assigned:

If the VM is configured with Accelerated Networking, a second network interface is created for each virtual NIC that is configured. The second interface is an SR-IOV Virtual Function (VF) offered by the physical network NIC in the Azure host. The VF interface shows up in the Linux guest as a PCI device, and uses the Mellanox “mlx4” or “mlx5” driver in Linux, since Azure hosts use physical NICs from Mellanox. Most network packets go directly between the Linux guest and the physical NIC without traversing the virtual switch or any other software that runs on the host. Because of the direct access to the hardware, network latency is lower and less CPU time is used to process network packets when compared with the synthetic interface.

Different Azure hosts use different models of Mellanox physical NIC, so Linux automatically determines whether to use the “mlx4” or “mlx5” driver. Placement of the VM on an Azure host is controlled by the Azure infrastructure. With no customer option to specify which physical NIC that a VM deployment uses, the VMs must include both drivers. If a VM is stopped/deallocated and then restarted, it might be redeployed on hardware with a different model of Mellanox physical NIC. Therefore, it might use the other Mellanox driver.

If a VM image doesn't include a driver for the Mellanox physical NIC, networking capabilities will continue to work at the slower speeds of the virtual NIC, even though the portal, Azure CLI, and Azure PowerShell will still show the Accelerated Networking feature as enabled.

You may also find suggestions in this thread helpful : https://github.com/MicrosoftDocs/azure-docs/issues/45303#issuecomment-958860583