Networking DOCA SDK Documentation

Virtio-net Service Guide Release Notes

The following subsections provide information on virtio-net service new features, interoperability, known issues, and bug fixes.

Changes and New Features in This Release

  • Bug fixes

In DOCA 3.3.0, the mrg_rxbuf and packed_vq parameters will no longer be supported in the virtnet.conf configuration file. Configuration of the mrg_rxbuf and packed_vq features must now be performed using the CLI modify device option.

Bug Fixes

Ref #

Issue

4992806 / 5091739

Description: When Dynamic Interrupt Moderation (Net DIM) was disabled or torn down on a virtio-net device, the controller could free the DIM data structures on the DPA (the per-VQ DIM list and bucket buffers) and destroy the DIM timer threads while DPA execution units were still accessing them. This use-after-free caused the DPA application to crash.

Keyword: netdim

Detected in version: 3.2.2

4594583 / 5074577

Description: A link status race condition during hotplug PF initialization can fail MSI-X vector allocation. The controller aborts setup to prevent a crash, resulting in the host detecting a NIC with an all-zero MAC address.

Keyword: Modify; device

Detected in version: 3.2.2

4622439 / 5074569

Description: The live migration process hangs at 99.99% if the virtio-net-controller service is restarted during an ongoing kernel-based migration.

Keyword: Live Migration; restart

Detected in version: 3.2.2

4944820 / 5074559

Description: During a live update, the virtio-net emulator (virtio_net_emu) may encounter a segmentation fault (SIGSEGV) and crash.

Keyword: live update

Detected in version: 3.2.2

4952581

Description: A shutdown reference leak in the virtio-net RPC layer, triggered by an invalid max_queue_size modify request, has been fixed to ensure proper cleanup on all error paths.

Keyword: max_queue_size; modify

Detected in version: 3.2.2

Known Issues

The following are known limitations of this NVIDIA® BlueField® virtio-net software version.

Ref #

Issue

4630265 / 5103112

Description: Restarting the virtio-net-controller service (e.g., using systemctl restart virtio-net-controller) while the virtio-net driver is bound can cause a soft-lockup call trace in virtnet_send_command(), since control-VQ commands do not complete until the restart finishes (up to ~1.5 minutes with many VFs). This is expected behavior from the one-way virtio control plane and does not cause data loss or functional impact.

Workaround: Unbind the device from the virtio-net driver before you restart the virtio-net-controller service. Rebind the device after the restart completes.

Keyword: Controller; restart; virtnet_send_command; soft lockup; control VQ

Reported in version: 3.2.3

4498529

Description: Windows VM may take a lot of time to load when VLAN tagging is enabled.

Workaround: Disable VLAN tagging.

Keyword: Windows; VLAN

Reported in version: 25.10

4534273

Description: After installing a new version, virtnet -v or --version displays the version of the updated CLI, not the source or target upgrade versions.

Workaround: Run virtnet version to view both the original and destination versions.

Keyword: CLI; version; update

Reported in version: 25.07

3879093

Description: When creating a large number of virtio-net VFs, the representor name of the SF may not be renamed.

Workaround: Use the ip command to rename the representor manually.

Keyword: Representor

Reported in version: 24.10

3943905

Description: Host OS kernel <3.19 does not support 31 hotplug devices.

Workaround: Avoid hotplugging more than 20 devices if host OS kernel is <3.19, or upgrade the kernel to ≥3.19.

Keyword: Host OS; kernel; hotplug

Reported in version: 24.07

4022160

Description: Feature bit VIRTIO_NET_F_CTRL_VLAN is not supported. Enabling it from the hotplug device may results in anomalous behavior.

Workaround: Disable VIRTIO_NET_F_CTRL_VLAN.

Keyword: Feature bit

Reported in version: 24.07

4001261

Description: The virtnet.conf file does not check invalid values such as negative numbers or 0.

Workaround: N/A

Keyword: Virtnet; config; invalid value

Reported in version: 24.07

3965598

Description: Admin-VQ-based transitional VF show a vf_get error when the controller is restarted. However, VF functionality is not affected.

Workaround: N/A

Keyword: Admin VQ; transitional device

Reported in version: 24.07

3961951

Description: Out-of-memory call trace occurs when creating many (>300) VFs on a BlueField running OpenEuler or CentOS 7.6.

Workaround: Update the kernel to support shared RQ.

Keyword: OOM; OpenEuler; CentOS 7.6; virtual function

Reported in version: 24.07

3862683

Description: Creating VFs and hotplug PFs in parallel can lead to controller crash.

Workaround: Create VFs followed by hotplug PF or vice versa.

Keyword: Virtio-net emulation

Reported in version: 1.9.0

3665070

Description: Virtio-net controller fails to load if DPA_AUTHENTICATION is enabled.

Workaround: N/A

Keywords: Virtio-net; DPA

Reported in version: DOCA 2.5.0

3538486

Description: When removing LAG configuration from BlueField, a kernel warning for uverbs_destroy_ufile_hw is observed if virtio-net-controller is still running.

Workaround: Stop virtio-net-controller service before cleaning up bond configuration.

Keywords: Virtio-net; LAG

Reported in version: DOCA 2.2.0

3683801

Description: Starting from kernel 5.14, the virtio-net TX path has a logic which may trigger infinite loop when vq is broken (e.g., device is removed) under heavy traffic.

Workaround: N/A

Keyword: Virtio-net

Reported in version: DOCA 1.8.0

3714522

Description: When creating/destroying VFs back to back, make sure the virtio-net controller side does not see any alive VF before recreating them from the guest OS (i.e., virtnet query).

Workaround: N/A

Keyword: Virtio-net; VFs

Reported in version: DOCA 1.8.0

3694402

Description: When restarting the virtio-net-controller from the DPU while the guest OS is booting, the guest OS may see kernel call trace while the controller is preparing the device. It recovers once the controller starts.

Workaround: N/A

Keyword: Virtio-net; hotplug; restart

Reported in version: DOCA 1.8.0

3633453

Description: Jumbo MTU is only supported on a guest OS with kernel 4.11 and above.

Workaround: N/A

Keyword: Virtio-net; jumbo MTU

Reported in version: DOCA 1.7.0

3021967

Description: When rebooting a DPU with a large number of VFs created on host, VF recovery may fail due to timeout.

Workaround: Restart the driver on the host after the DPU is up.

Keyword: Reboot; VFs

Reported in version: DOCA 1.7.0

3232444

Description: After live migration of virtio-net devices using the VFE driver, the max_queues_size output from the virtnet list may be wrong. This does not affect the actual value.

Workaround: N/A

Keywords: Virtio-net; live migration

Reported in version: DOCA 1.4.0

2801780

Description: When running virtio-net-controller with host kernel older than 3.10.0-1160.el7, host virtio driver may get error (Unexpected TXQ (13) queue failure: -28) from dmesg in traffic stress test.

Workaround: N/A

Keywords: Virtio-net; error

Reported in version: DOCA 1.2.0

2870213

Description: Servers do not recover after configuring PCI_SWITCH_EMULATION_NUM_PORT to 32 followed by power cycle.

Workaround: Clear NVRAM and reset mlxconfig to default

Keywords: Virtio-net; power cycle

Reported in version: DOCA 1.2.0

2685191

Description: Once virtio-net is enabled, the mlx5 Windows VF becomes unavailable.

Workaround: N/A

Keywords: Virtio-net; virtual function; WinOF-2

Reported in version: DOCA 1.2.0

2702395

Description: When a device is hot-plugged from the virtio-net controller, the host OS may hang when warm reboot is performed on the host and Arm at the same time.

Workaround: Reboot the host OS first and only then reboot DPU.

Keywords: Virtio-net controller; hot-plug; reboot

Reported in version: DOCA 1.2.0

Last updated: