はじめに
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 ファイルを編集します。
--- 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となっています。
ログ
障害時のログは次のようになっています。このログは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ファイルは次のようになっています。
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ドライバを使うだろうという想定でしたが、実際には次のようなエラーメッセージによって利用することができませんでした。
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)**となっています。
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が動作しました。
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の出力は次のようになっています。
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を追加してから再起動してみます。
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以外の問題が発生するようです。
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を無効化することで対応しています。
以上