はじめに

Ubuntu 22.04でFD.io vppを利用している環境で再起動後にシステムがネットワークに接続できなくなりました。

同じく6.8.0カーネルを利用している最新のUbuntu 24.04 LTSでも同様です。

状況を調査した結果を残しておきます。

この現象はIOMMU(Inetl VT-d, AMD IOMMU)が有効になったシステムと6.8.0-40カーネルとの間で発生しています。問題への対応としてはUEFIでVT-dT(IOMMU)をOffにする、あるいはカーネルのコマンドラインでintel_iommu=off (amd_iommu=off)を指定することをお勧めします。もちろんIOMMUを有効にしたままvfio-pciモジュールを有効にする方法もありますが、環境によっては素直に動作せず追加の調査・対応が必要になり諦めたケースがありました。

環境

障害が発生するのは次のような環境です。

OS: Ubuntu 22.04.4 LTS + Ubuntu 24.04 LTS
Kernel: linux-image-6.8.0-40-generic (linux-image-generic-hwe-22.04)
Arch: x86_64
VPP: 24.06-release and 24.10-rc0~167-gf02e74678~b1553

Ubuntu 22.04ではHWEカーネルを含む以下のバージョンでは問題なく動作します。

5.15.0-118-generic
6.5.0-45-generic

問題なく動作しているシステム(APU2)の状況

自宅でFlets光に接続するため利用しているPC Engines社製のAPU2では問題なく動作しています。Ubuntu 24.04なのでカーネルはデフォルトの6.8.0-40でした。NICはI211チップなのでigbモジュールを使用しています。

手元のUbuntu 24.04をインストールしているVMでは正常に動作していないため、Ubuntuのdistributionではなくカーネルのバージョンによって挙動が異なるようです。

NICのモジュール・ドライバによって挙動が異なる模様

原因は不明ですが動作する組み合わせがあるという事からは、NICのドライバ周りが原因の可能性がありそうです。

dhcp(ipv4)やnat44を使っていないので、それがポイントかと思ったのですが、Ubuntu 22.04.4と24.04のVM上のvmxnet3モジュールで同様の環境を構築したところAPU2では動作可能な設定でも停止します。

この結果からはやはりNICドライバ回りとDPDKとの間に問題がありそうです。

空いているAPU2にUbuntu 24.04を導入して不具合が再現するか確認したところ問題なく動作しました。このAPU2にUbuntu 22.04を導入して、HWEカーネルでも確認していますが、VMでは問題となった構成でもAPU2では問題なく動作しています。

HP Microserver Gen8にIntel PRO/1000 PT Dual Port Server Adapterを接続した Ubuntu 22.04 (HWE 6.8.0-40カーネル) + VPP 24.06 の環境でも同様の不具合が発生しています。この時のカーネルモジュールは"e1000e"です。

igbモジュールを利用するI350チップを搭載したNICに変更して不具合が発生するか確認する予定です。

これらのモジュールはいずれもDPDK Supported Hardware (INTEL)のリストに入っています。

当初はモジュールの差異が障害発生の原因だと思われましたが、最終的にIOMMUを無効化することでigcモジュールでも問題なくVPPが動作しています。

状況の調査

まだ原因がNICドライバにあるのか判然としませんが、調査の内容をメモとして残します。

古いカーネルからのブート

Ubuntu Serverデフォルトの設定だとGRUBのメニューは表示されないようになっていると思います。

メニューを表示させるには次のように /etc/default/grub ファイルを編集します。

/etc/default/grubの編集

--- grub.orig   2024-08-19 13:51:08.000866700 +0900
+++ grub        2024-08-19 08:29:19.083812605 +0900
@@ -4,8 +4,8 @@
 #   info -f grub -n 'Simple configuration'
 
 GRUB_DEFAULT=0
-GRUB_TIMEOUT_STYLE=hidden
-GRUB_TIMEOUT=0
+GRUB_TIMEOUT_STYLE=menu
+GRUB_TIMEOUT=10
 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
 GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200n8"
 GRUB_CMDLINE_LINUX=""

古い説明だとGRUB_HIDDEN_TIMEOUTを操作するよう書かれているものもありますが、22.04.4ではGRUB_TIMEOUT_STYLEを編集するようになっています。

この他にGRUB_TIMEOUT_STYLE=hiddenをコメントしても同様にメニューが表示されます。

GRUB_TIMEOUT_STYLE と GRUB_TIMEOUT の2行を変更したら次の要領でGRUBを更新し、再起動します。

$ sudo update-grub
$ sudo shutdown -r now

GRUB_TIMEOUTは-1にすると人間が操作しない限り起動しなくなりますので、停電からの自動復旧などを期待する場合には避けたほうがいいと思います。

VPPとDPDKのバージョンについて

VPP 24.06が使用するのはDPDK 24.03で、このバージョンのDPDKはlinux 6.8.0以上をテスト環境として利用しています。ただUbuntuでのテストは22.04.3でとなっているので、DPDK 24.07で何か改善されているかもしれませんが、現状ではVPP 24.10-rcでもDPDKのバージョンは24.03.0となっています。

Release notes for VPP 24.06
DPDK Release 24.03

ログ

障害時のログは次のようになっています。このログはVPP 24.10-rc0のものとなっています。

24.06-releaseのログはもっとシンプルですが、いずれにしても動作しません。

エラーメッセージ

Aug 19 04:31:32 ub2204 systemd[1]: Starting vector packet processing engine...
Aug 19 04:31:32 ub2204 systemd[1]: Started vector packet processing engine.
Aug 19 04:31:32 ub2204 vpp[2076]: vat-plug/load: vat_plugin_register: idpf plugin not loaded...
Aug 19 04:31:34 ub2204 vpp[2076]: received signal SIGSEGV, PC 0x7fc4847fb7b8, faulting address 0x7fc540003ef0
Aug 19 04:31:34 ub2204 vpp[2076]: Code:  c7 03 00 00 00 00 5a 5b 5d c3 55 48 89 fd bf 08 00 00 00 53
Aug 19 04:31:34 ub2204 vpp[2076]: #0  0x00007fc4847fb7b8
Aug 19 04:31:34 ub2204 vpp[2076]:      from /usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so
Aug 19 04:31:34 ub2204 vpp[2076]: #1  0x00007fc485180193
Aug 19 04:31:34 ub2204 vpp[2076]:      from /usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so
Aug 19 04:31:34 ub2204 vpp[2076]: #2  0x00007fc484a2a234
Aug 19 04:31:34 ub2204 vpp[2076]:      from /usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so
Aug 19 04:31:34 ub2204 vpp[2076]: #3  0x00007fc4852d8bf7 clib_sysfs_read_bitmap + 0x5c57
Aug 19 04:31:34 ub2204 vpp[2076]:      from /usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so
Aug 19 04:31:34 ub2204 vpp[2076]: #4  0x00007fc4852dbcc4 clib_sysfs_read_bitmap + 0x8d24
Aug 19 04:31:34 ub2204 vpp[2076]:      from /usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so
Aug 19 04:31:34 ub2204 vpp[2076]: #5  0x00007fc4cd4dc45a unserialize_vnet_interface_state + 0xa4a
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvnet.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #6  0x00007fc4cd4f9edb vnet_pcap_dispatch_trace_configure + 0x2a3b
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvnet.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #7  0x00007fc4cd01a497 vlib_cli_input + 0xd37
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #8  0x00007fc4cd01a155 vlib_cli_input + 0x9f5
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #9  0x00007fc4cd01a155 vlib_cli_input + 0x9f5
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #10 0x00007fc4cd0197dd vlib_cli_input + 0x7d
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #11 0x00007fc4cd0a1bb0 vlib_unix_cli_set_prompt + 0x10e70
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #12 0x00007fc4cd01a497 vlib_cli_input + 0xd37
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #13 0x00007fc4cd0197dd vlib_cli_input + 0x7d
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #14 0x00007fc4cd0a64c4 vlib_unix_main + 0x994
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #15 0x00007fc4cd03c067 vlib_exit_with_status + 0x537
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvlib.so.24.10
Aug 19 04:31:34 ub2204 vpp[2076]: #16 0x00007fc4cee3f928 clib_calljmp + 0x18
Aug 19 04:31:34 ub2204 vpp[2076]:      from /lib/x86_64-linux-gnu/libvppinfra.so.24.10
Aug 19 04:31:34 ub2204 systemd[1]: vpp.service: Main process exited, code=dumped, status=6/ABRT
Aug 19 04:31:34 ub2204 systemd[1]: vpp.service: Failed with result 'core-dump'.

自前でパッケージをbuildしてみる

VMWare上に同様の環境でvppを動作させているVMがあるので、まずはこれを対象に確認していきます。

パッケージの作成自体は公式ドキュメントに解説があります。

ネットワークに接続できる状態で次のようにパッケージをビルドしておきます。

$ sudo apt install git
$ git clone https://github.com/FDio/vpp.git
$ cd vpp
$ git checkout refs/tags/v24.06 -b my_v24.06
$ sudo make install-dep
$ make install-ext-deb
$ make pkg-deb

makeコマンドの引数に pkg-deb 以外に指定できるタスクを確認したい時は、vppディレクトリで make helpを実行してください。

make dpkg-debコマンドは実行にかなり時間がかかり、手元の環境では1時間以上かかっています。

$ cd build-root/
$ sudo dpkg -i vpp_24.06-release_amd64.deb \
    libvppinfra-dev_24.06-release_amd64.deb \
    vpp-plugin-core_24.06-release_amd64.deb \
    vpp-plugin-dpdk_24.06-release_amd64.deb

ここで、linux-image-6.8.0-40-generic で動作するか確認します。

$ sudo systemctl stop vpp
$ sudo vpp -c /etc/vpp/startup.conf
bvi0
Aborted

残念ながらうまくいきません。

少し設定ファイルを変更していくと、設定したデバイスをupしようとするとAbortedで落ちるのが分かります。

startup-configで指定している/etc/vpp/local.cfgファイルは次のようになっています。

/etc/vpp/local.cfg

bvi create instance 0
set int mac address bvi0 0e:e3:e9:ff:ff:01
set int l2 bridge bvi0 1 bvi
set int ip address bvi0 192.168.2.1/24
set int state bvi0 up

create tap host-if-name tap0 host-ip4-addr 192.168.2.2/24 host-ip4-gw 192.168.2.1
set int l2 bridge tap0 1
set interface l2 bridge intgw 1
#set int state intgw up

vppctlでintgwやtap0をupにしてみます。

$ sudo vppctl show int
              Name               Idx    State  MTU (L3/IP4/IP6/MPLS)     Counter          Count     
bvi0                              3      up          9000/0/0/0     
dhcpcl                            2     down         2026/0/0/0     
intgw                             1     down         2026/0/0/0     
local0                            0     down          0/0/0/0       
tap0                              4     down         9000/0/0/0

$ sudo vppctl set int state tap0 up
$ sudo vppctl show int
              Name               Idx    State  MTU (L3/IP4/IP6/MPLS)     Counter          Count     
bvi0                              3      up          9000/0/0/0     rx packets                    10
                                                                    rx bytes                     656
                                                                    drops                         10
                                                                    ip6                           10
dhcpcl                            2     down         2026/0/0/0     
intgw                             1     down         2026/0/0/0     tx-error                      10
local0                            0     down          0/0/0/0       
tap0                              4      up          9000/0/0/0     rx packets                    10
                                                                    rx bytes                     796
                                                                    drops                         10

$ sudo vppctl set int state intgw up
## vpp側ではAbortedが表示されプロセスが終了している
$ sudo vppctl show int
connect: Connection refused

bvi0デバイスやtap0デバイスの作成はできますが、startup.confのdpdk { dev ... {...} } で定義しているデバイスをupしようとすると6.8.0カーネルではSEGVが発生しています。

GDBによるデバッグ

gdbでvppを起動します。

$ sudo make STARTUP_CONF=/etc/vpp/startup.conf debug
...
$ run
Starting program: /work/vpp/build-root/install-vpp_debug-native/vpp/bin/vpp -c /etc/vpp/startup.conf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
vpp[118533]: perfmon: skipping source 'intel-uncore' - intel_uncore_init: no uncore units found
[New Thread 0x7fffa5c00640 (LWP 118536)]
[New Thread 0x7fffa5200640 (LWP 118537)]
[New Thread 0x7fffa4e00640 (LWP 118538)]
bvi0

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x00007fffaecfd7f3 in rte_write32_relaxed (addr=0x800080003ef0, value=0) at ../src-dpdk/lib/eal/include/generic/rte_io.h:310
310             *(volatile uint32_t *)addr = value;

backtraceは次のようになりました。

(gdb) bt 12
#0  0x00007fffaecfd7f3 in rte_write32_relaxed (addr=0x800080003ef0, value=0) at ../src-dpdk/lib/eal/include/generic/rte_io.h:310
#1  rte_write32 (addr=0x800080003ef0, value=0) at ../src-dpdk/lib/eal/include/generic/rte_io.h:373
#2  vmxnet3_enable_intr (hw=0xac039d480, intr_idx=4294967262) at ../src-dpdk/drivers/net/vmxnet3/vmxnet3_ethdev.c:212
#3  0x00007fffaed02de1 in vmxnet3_dev_rx_queue_intr_enable (dev=0x7fffafbaa580 <rte_eth_devices+16576>, queue_id=0) at ../src-dpdk/drivers/net/vmxnet3/vmxnet3_ethdev.c:1942
#4  0x00007fffa9daeae2 in rte_eth_dev_rx_intr_enable (port_id=1, queue_id=0) at ../src-dpdk/lib/ethdev/rte_ethdev.c:5698
#5  0x00007fffaf1c55c4 in dpdk_setup_interrupts (xd=0x7fffbc95a940) at /work/vpp/src/plugins/dpdk/device/common.c:330
#6  0x00007fffaf1c5490 in dpdk_device_start (xd=0x7fffbc95a940) at /work/vpp/src/plugins/dpdk/device/common.c:405
#7  0x00007fffaf1d0763 in dpdk_interface_admin_up_down (vnm=0x7ffff7d78108 <vnet_main>, hw_if_index=2, flags=1) at /work/vpp/src/plugins/dpdk/device/device.c:476
#8  0x00007ffff6f0ca58 in vnet_sw_interface_set_flags_helper (vnm=0x7ffff7d78108 <vnet_main>, sw_if_index=2, flags=VNET_SW_INTERFACE_FLAG_ADMIN_UP, helper_flags=0)
    at /work/vpp/src/vnet/interface.c:460
#9  0x00007ffff6f0cdca in vnet_sw_interface_set_flags (vnm=0x7ffff7d78108 <vnet_main>, sw_if_index=2, flags=VNET_SW_INTERFACE_FLAG_ADMIN_UP) at /work/vpp/src/vnet/interface.c:514
#10 0x00007ffff6f3cdaf in set_state (vm=0x7fffb6801740, input=0x7fffa5ebcb98, cmd=0x7fffb9215110) at /work/vpp/src/vnet/interface_cli.c:927
#11 0x00007ffff7e69770 in vlib_cli_dispatch_sub_commands (vm=0x7fffb6801740, cm=0x7ffff7f67a70 <vlib_global_main+48>, input=0x7fffa5ebcb98, parent_command_index=20)
    at /work/vpp/src/vlib/cli.c:639
(More stack frames follow...)

valueが0なのは良いとして割り込みを有効化するのに書き込むアドレスの取得方法は一覧から取得した値を8倍していたりして、アラインメントが8倍になるだろうからインデックスだけを管理しているのでしょうがアドレスを格納した方が毎回8倍するよりも良くない？と思わなくもありません。

2^3なら単純なシフトに最適化されるので、どちらでも大差ないのか、元々インデックスで管理する仕様なのか良く分かっていません。

I350 NICによる確認

10Gtek社製のI350 NICを入手したので、HP Microserver Gen8に付け替えて様子を確認します。

まず付け替えただけで、igbドライバを使うだろうという想定でしたが、実際には次のようなエラーメッセージによって利用することができませんでした。

6.8.0-45カーネルで動作した時のsyslogから抜粋

Aug 22 09:00:11 ub2204 vpp[1878]: vpp[1878]: vlib_pci_bind_to_uio: Skipping PCI device 0000:05:00.0: device is bound to IOMMU group and vfio-pci driver is not loaded   
Aug 22 09:00:11 ub2204 vpp[1878]: vlib_pci_bind_to_uio: Skipping PCI device 0000:05:00.0: device is bound to IOMMU group and vfio-pci driver is not loaded                   
Aug 22 09:00:11 ub2204 vpp[1878]: vpp[1878]: vlib_pci_bind_to_uio: Skipping PCI device 0000:05:00.1: device is bound to IOMMU group and vfio-pci driver is not loaded        
Aug 22 09:00:11 ub2204 vpp[1878]: vlib_pci_bind_to_uio: Skipping PCI device 0000:05:00.1: device is bound to IOMMU group and vfio-pci driver is not loaded                     
Aug 22 09:00:11 ub2204 vpp[1878]: EAL: FATAL: rte_service_init() failed                                                                                          
Aug 22 09:00:11 ub2204 vpp[1878]: dpdk_config: rte_eal_init returned -1

ここら辺からIOMMUが怪しいのではないかという考えが出てきました。

動くことが分かっている6.5.0カーネルで起動したところ次のようにkernel driverとkernel moduleの組合せは、**(uid_pci_generic, igb)**となっています。

6.5.0-45カーネルで動作した時のlspci -vの出力

05:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
        Subsystem: Beijing Sinead Technology Co., Ltd. I350 Gigabit Network Connection
        Kernel driver in use: uio_pci_generic
        Kernel modules: igb
05:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
        Subsystem: Beijing Sinead Technology Co., Ltd. I350 Gigabit Network Connection
        Kernel driver in use: uio_pci_generic
        Kernel modules: igb

HP Microserver Gen8のNICをI350に交換した時にBIOSでIntel VT-d(IOMMU)が有効になっていて、6.5.0-45まではuio_pci_genericドライバが読み込まれていたのですが、これが変わっていたため、/etc/modulesで明示的にvfio-pci, vfio, vfio_iommu_type1を指定したところ、メッセージは変化したもののvppの初期化に失敗していました。

このためUEFIでVT-dだけ無効化したところ、無事にuio_pci_genericで6.8.0-40カーネルでVPPが動作しました。

VT-dを無効化した後、6.8.0-40で起動した時のlspci -vの出力

05:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
        Subsystem: Beijing Sinead Technology Co., Ltd. I350 Gigabit Network Connection
        Physical Slot: 1
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at fbd80000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at 4020 [size=32]
        Memory at fbd70000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at f8080000 [virtual] [disabled] [size=512K]
        Capabilities: <access denied>
        Kernel driver in use: uio_pci_generic
        Kernel modules: igb

別の2.5G NICを搭載していてigcモジュールで動作しているサーバー(protectli社製 VP2420)のlspciの出力は次のようになっています。

6.8.0-40でのlspci -vの出力

04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)
        Subsystem: Intel Corporation Ethernet Controller I225-V
        Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 15
        Memory at 7fd00000 (32-bit, non-prefetchable) [size=1M]
        Memory at 7ff00000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at 7fe00000 [disabled] [size=1M]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number 64-62-66-ff-ff-21-f0-da
        Capabilities: [1c0] Latency Tolerance Reporting
        Capabilities: [1f0] Precision Time Measurement
        Capabilities: [1e0] L1 PM Substates
        Kernel driver in use: igc
        Kernel modules: igc

/etc/default/grubでGRUB_CMDLINE_LINUX_DEFAULTにintel_iommu=offを追加してから再起動してみます。

intel_iommu=offを指定した6.8.0-40とigcモジュールでのlspci -vの出力

04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I225-V (rev 03)
        Subsystem: Intel Corporation Ethernet Controller I225-V
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at 7fd00000 (32-bit, non-prefetchable) [size=1M]
        Memory at 7ff00000 (32-bit, non-prefetchable) [size=16K]
        Expansion ROM at 7fe00000 [disabled] [size=1M]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [70] MSI-X: Enable- Count=5 Masked-
        Capabilities: [a0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number 64-62-66-ff-ff-21-ee-a6
        Capabilities: [1c0] Latency Tolerance Reporting
        Capabilities: [1f0] Precision Time Measurement
        Capabilities: [1e0] L1 PM Substates
        Kernel driver in use: uio_pci_generic
        Kernel modules: igc

自動的にuio_pci_genericがロードされて問題なく動作するようになりました。

IOMMUを無効化してもvmxnet3は引き続き稼動しない

IOMMUを検証用のVM上でのみ引き続き問題が発生しています。6.5.0などのカーネルにすれば問題は解決するのでIOMMU以外の問題が発生するようです。

障害が発生している状態でのlspci -vの出力

0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
        DeviceName: Ethernet0
        Subsystem: VMware VMXNET3 Ethernet Controller
        Physical Slot: 160
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at fd4fc000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd4fd000 (32-bit, non-prefetchable) [size=4K]
        Memory at fd4fe000 (32-bit, non-prefetchable) [size=8K]
        I/O ports at 4000 [size=16]
        Expansion ROM at fd400000 [virtual] [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [48] Express Endpoint, MSI 00
        Capabilities: [84] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [9c] MSI-X: Enable- Count=25 Masked-
        Capabilities: [100] Device Serial Number 00-0c-29-ff-ff-51-d6-cc
        Kernel driver in use: uio_pci_generic
        Kernel modules: vmxnet3

VMware Workstation Proでのvmxnet3の機能はおまけのようなものなのですが、デフォルトのe1000モジュールを利用しても6.8.0カーネルでは起動させることができませんでしたが、iommuを有効にして/etc/modulesにvfio-pciを追加すると、e1000モジュールとvfio-pciドライバで問題なく稼動しました。

02:05.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
        DeviceName: Ethernet0
        Subsystem: VMware PRO/1000 MT Single Port Adapter
        Physical Slot: 37
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 19, IOMMU group 1
        Memory at fd560000 (64-bit, non-prefetchable) [size=128K]
        Memory at fdfd0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at 2080 [size=64]
        Expansion ROM at fd530000 [virtual] [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
        Capabilities: [e4] PCI-X non-bridge device
        Kernel driver in use: vfio-pci
        Kernel modules: e1000

結論

障害の理由はkernel 6.8.0からNICデバイスでのIOMMUが有効になり、VPP(DPDK)がvfio-pciドライバを要求するようになったことだと思われます。

少なくともIOMMUを無効化することで、igb, igc カーネルモジュールを利用するサーバーでは改善することを確認できました。

IOMMUはUEFIの画面からIntel CPUであればVT-dを無効化するか、AMDであれば仮想化やSVMといったメニューの中にあるIOMMUをDisableにすることで対応できます。

カーネルのコマンドラインで対応するのであれば、/etc/default/grubのGRUB_CMDLINE_LINUX_DEFAULT=にintel_iommu=offやamd_iommu=offを指定することで対応できます。

IOMMUの有効化とVPPを一緒に使うということはあまりないと思うのですが、vfio-pciドライバで動作するようにするべきなのだろうと思います。

vfio-pciモジュールは明示的に動作させる必要があるため/etc/modulesなどの編集が必要です。

現状ではvfio-pciを有効にしてもVPPが動作しないため、IOMMUを無効化することで対応しています。

以上