NIC mapping maps DPDK NICs twice if they are already configured when os-net-config runs a second time

[Dan Sneddon]

When os-net-config runs for the first time there is no entry in /sys/net for the DPDK NICs, so we look in /var/lib/os-net-config/dpdk_mapping.yaml for the list of DPDK NICs and add them to the NIC mapping list.

If os-net-config has been run before and the DPDK NICs are already active, there is an entry in /sys/net and also an entry in /var/lib/os-net-config/dpdk_mapping.yaml for the NIC. This results in the same NIC being added to the list of active NICs twice.

For example, in the following log you can see that p2p1, p2p2, p3p1, and p3p2 are each added to the list of active NICs twice:

Jan 11 12:03:14 hostname os-collect-config: [2021/01/11 11:58:07 AM] [INFO] Active nics are ['em1', 'em2', 'p1p1', 'p1p2', 'p2p1', 'p2p1', 'p2p2', 'p2p2', 'p3p1', 'p3p1', 'p3p2',
'p3p2']
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic2 mapped to: em2
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic3 mapped to: p1p1
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic4 mapped to: p1p2
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic7 mapped to: p2p2
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic5 mapped to: p2p1
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic1 mapped to: em1
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic11 mapped to: p3p2
Jan 11 12:03:14 cpt0-dpdk-dell-tovb os-collect-config: [2021/01/11 11:58:07 AM] [INFO] nic9 mapped to: p3p1

In order to fix this problem, we should check to see if a NIC name exists in the list of active NICs before adding it in utils._ordered_nics():

241 # Adding nics which are bound to DPDK as it will not be found in '/sys'
242 # after it is bound to DPDK driver.
243 contents = get_file_data(_DPDK_MAPPING_FILE)
244 if contents:
245 dpdk_map = yaml.safe_load(contents)
246 for item in dpdk_map:
247 # If the DPDK drivers are bound to a VF, the same needs
248 # to be skipped for the NIC ordering
249 nic = item['name']
250 if _is_vf(item['pci_address']):
251 logger.info("%s is a VF, skipping it for NIC ordering" % nic)
252 elif _is_embedded_nic(nic):
253 logger.info("%s is an embedded DPDK bound nic" % nic)
254 embedded_nics.append(nic) # <-- Check needed here
255 else:
256 logger.info("%s is an DPDK bound nic" % nic)
257 nics.append(nic) # <-- Check needed here

[Dan Sneddon (dsneddon)]

Minor correction, the active NICs appear in /sys/class/net, not in /sys/net.

[Saravanan KR (skramaja)]

Intel Nics
----------
When the os-net-config runs for the first time, the nic will be found in /sys/class/net, but it will be bound to vfio-pci driver. After it is bound to the driver, the entry in dpdk_mapping.yaml is added as the interface will not be visible to the kernel. From then on the kernel entry for that nic will not be available. Even in reboot, driverctl which runs during the boot ensures that driver is bound to the nics before starting the network.service and openvswitch.service.

Mellanox Nics
-------------
There should not be an entry for Mellanox nics as we don't change the driver.

I am trying to understand on which case it is available in both the places.

[Dan Sneddon (dsneddon)]

Saravanan, I'm wondering if it has something to do with enabling LACP on the bond?

I don't have access to the environment where this was observed, but I believe the proposed patch will correct for this issue no matter what the specific circumstances are where it appears.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-net-config 14.0.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-net-config 13.2.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-net-config 11.5.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/os-net-config 12.3.4 release.