Product Announcements

Deciphering NIC Capabilities from log entries

Time once again for a down and dirty, bits and bytes style guest post! One of our Consulting Architects, Kamau Wanguhu, put this post together with some guidance from engineering…  

You may have seen messages like those below in your logs and wondered what neat capabilities are being enabled on your network card (NIC).

ESXsrv01 vmkernel: 22:04:29:43.583 cpu1:1198)Uplink: 2491: Setting capabilities 0x0 for device vmnic4
ESXsrv01 vmkernel: 22:04:29:43.583 cpu1:1198)Uplink: 2491: Setting capabilities 0x0 for device vmnic5
ESXsrv01 vmkernel: 22:04:59:11.410 cpu0:1235)Uplink: 2491: Setting capabilities 0x300 for device vmnic2 ESXsrv01 vmkernel: 22:04:59:11.410 cpu0:1235)Uplink: 2491: Setting capabilities 0x300 for device vmnic3 ESXsrv01 vmkernel: 22:04:59:11.410 cpu0:1235)Uplink: 2491: Setting capabilities 0x2b for device vmnic2
ESXsrv01 vmkernel: 22:04:59:11.410 cpu0:1235)Uplink: 2491: Setting capabilities 0x2b for device vmnic3

The magic decoder ring …

The HEX codes we use to decode the “Setting Capabilities” for the above style log messages are as follows:

0x0001 Capable of scatter-gather transmits
0x0002 can checksum only TCP/UDP over IPv4
0x0008 Can use DMA to high memory locations
0x0020 Supports TCP Segmentation offload, TSO
0x0100 Can do VLAN tagging in HW
0x0200 Can do VLAN untagging in HW

Decoding …

So now off to the fun stuff of decoding our log file output….

The first log entry sets the capabilities to 0x0. This is logged when the last virtual port of a portgroup that the uplink is assigned to is disconnected. In other words, the hardware capability is no longer needed, as no traffic will be sent over these uplinks (vmnic4 and vmnic5).

The next capability that is set is 0x300 for vmnic2 and vmnic3. From the table above we can get 0x300 by adding 0x0200 and 0x0100. This means that we are enabling:

0x0100 VLAN tagging in hardware.
0x0200 VLAN untagging in hardware

The next capability that is set is 0x2b. From this we can tell we are enabling:

0x0001 scatter-gather transmits
0x0002 checksum only TCP/UDP over IPv4
0x0008 DMA to high memory
0x0020 TCP Segmentation offload, TSO

as 0x0001 + 0x0002 + 0x0008 + 0x0020 + = 0x002b

And that is all there is to translating the NIC “Setting Capabilities” log entries!

This often poses an additional question: “Can one use NICs from different manufacturers in a vSwitch considering the NICs will probably have different capabilities?”

In reality it should not matter what low level capabilities your NIC has or which ones are enabled and used by the VMKernel. Most capabilities that are not available on your particular NIC, the VMKernel will handle in software. As such you can have a vSwitch configured with two NICs, one capable of TSO and the other not. VMKernel will use the TSO capabilities of the NIC that has it, if a failover occurs to the NIC without TSO capabilities, the VMKernel will just handle segmentation in software before delivering data to the NIC.

Note that we are baring some of the innards of ESX 3.5, so be aware the codes are subject to change in future releases.