NVIDIA Docs Hub NVIDIA Networking BlueField DPUs / SuperNICs & DOCA DOCA Documentation v2.10.0 SNAP Virtio-fs Service Release Notes

SNAP Virtio-fs Service Release Notes

The release notes provide information for the DOCA SNAP Virtio-fs Service such as changes and new features, software known issues, and bug fixes.

Changes and New Features

Key Features in Version 1.2.0-doca2.10.0

Virtio-fs container with customizable SPDK FSDEV.
Virtio-fs support for cache invalidate and fuse notification queue - required NVIDIA modified Virtio-fs driver.
Virtio-fs 254 IO queues per emulation function, total limitation is 2000.

Limitations

The following features are currently not supported in this version of the application:

End-to-end container solution does not support: device recovery, live update and live migration
Dynamic MSIX

Known Issues

DOCA SNAP Virtio-fs Issues

The following are known limitations of DOCA SNAP Virtio-fs software version.

Ref #	Issue
–	Description: Due to the lack of recovery support, it is not possible to perform any negative/resilience operations during IO traffic (e.g., destroy and restore). Info Restarting the device using `virtio_fs_device_stop` and `virtio_fs_device_start` is supported.
	Workaround: N/A
	Keywords: Recovery; negative/resilience operations
	Discovered in version: 1.0.0-doca2.8.0
–	Description: The following FUSE commands are unsupported: BMAP, SETUPMAPPING, REMOVEMAPPING.
	Workaround: N/A
	Keywords: FUSE
	Discovered in version: 1.0.0-doca2.8.0
–	Description: Application restart is not allowed if the application controller has processed FUSE commands.
	Workaround: Unload the virtio-fs driver on the host, then restart the application.
	Keywords: FUSE
	Discovered in version: 1.0.0-doca2.8.0
–	Description: The total number of virtio queues the application can create is limited to 2,000.
	Workaround: N/A.
	Keywords: Virtio queues
	Discovered in version: 1.0.0-doca2.8.0
–	Description: The following operations are not supported when using Linux's virtio-fs inbox/upstream kernel driver: FLR and the virtio-fs notification queue.
	Workaround: N/A
	Keywords: FLR; virtio-fs; inbox/upstream kernel driver
	Discovered in version: 1.0.0-doca2.8.0
–	Description: IO errors on host can be seen under high scale. Due to lack of mempool resources, more likely to be seen with 8 PFs.
	Workaround: Reduce overall outstanding IO traffic.
	Keywords: IO error, host error
	Discovered in version: 1.2.0-doca2.10.0
–	Description: I/O with size greater than 255 KB is not supported due to the data pool size restriction of 255 KB in the VirtioFS process running on the DPU.
	Workaround: Set the "max_xfer_size" in the `fsdev_aio_create` RPC to a value less than 255 KB. This value is used as "max_write" in the FUSE layer of the host kernel. If the I/O size exceeds `max_xfer_size` , the FUSE layer in the host kernel will split the I/O into smaller chunks. The default value of "max_xfer_size" in fsdev_aio_create RPC is 128KB. For example, If the user attempts an I/O operation of 1MB while "max_xfer_size" is set to 64KB, the FUSE layer on the host will split the request into 64KB chunks. As a result, the VirtioFS process on the DPU will receive 16 separate I/O requests (1MB ÷ 64KB).
	Keywords: IO error, host error, io_size
	Discovered in version: 1.2.0-doca2.10.0

OS or Vendor Issues

Info

The following are not DOCA SNAP Virtio-fs limitations.

Ref #	Issue
–	Description: If the FLR is initiated from the host by writing `1` to the `reset` file under `/sys/bus/pci/devices/bdf/` using the command `echo 1 > /sys/bus/pci/devices/0000\:29\:00.2/reset`, then the host driver does not create virtqueues, causing the mount point to remain stuck indefinitely.
	Workaround: FLR should only be performed without any mount over virtio-fs on the host. To run IO after FLR, reload the virtio-fs host driver.
	Keywords: Driver; FLR
	Discovered in version: 1.0.0-doca2.8.0
–	Description: On the host, when the virtio-fs mount is idle (i.e., no I/O operations), dmesg logs are filled with repeated AppArmor DENIED messages. These messages indicate that the ntpd service is being denied access to specific files by AppArmor. The ntpd service is trying to access `/snap/bin/` and `/etc/ssl/openssl.cnf`, but the AppArmor profile for ntpd does not permit these accesses, resulting in denied requests.
	Workaround: Modify the AppArmor profile for ntpd to grant the required read permissions. Locate the AppArmor profile for ntpd. It is typically located in `/etc/apparmor.d/` and named `usr.sbin.ntpd`. Edit the profile and add the required permissions by using a text editor. For example: Run: Copy Copied! `sudo nano /etc/apparmor.d/usr.sbin.ntpd` Add the following lines to allow ntpd to read the necessary files: Copy Copied! /snap/bin/ r, /etc/ssl/openssl.cnf r` Apply the changes by reloading the AppArmor profile: Copy Copied! `sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.ntpd`
	Keywords: AppArmor, ntpd
	Discovered in version: 1.0.0-doca2.8.0
–	Description: With a kernel version older than 6.10, if stress loading and unloading of the `virtio_pci` and `virtiofs` drivers is done in a loop, or mount and umount in a loop, then unmounting or unloading the driver may hang.
	Workaround: Add a delay of 1 second between loading and unloading of the drivers.
	Keywords: virtio_pci; virtiofs
	Discovered in version: 1.0.0-doca2.8.0

On This Page