docs: vpp: document that kernel prerequisites need their own commit and reboot (backport #2233)

[mergify]

Change Summary

VPP depends on kernel settings that live under system option kernel —
hugepages, and since T8460 also isolated CPU cores. They only take effect after
a reboot, and VPP validates them against the running kernel. Because vpp is
committed at priority 295 and system option at 9999, the two can never be
applied in the same commit: vpp.py always runs first, the kernel options are
never in place yet, and the VPP part is rejected with

Not enough free memory to start VPP!
2M HugePages memory: available 0.0 GB, required 3.2 GB
To add HugePages memory please use command
"set system option kernel memory hugepage-size ..." and reboot!

or, on rolling, with Not enough isolated CPU cores available. Both messages
point back at the very command the user just issued in that same commit.

The "Optimal Configuration Example" in
docs/vpp/configuration/dataplane/system.md showed exactly this failing
one-shot form — it mixed set system option kernel ... and set vpp settings resource-allocation cpu-cores '2' in a single block. Copying it always fails.
This PR splits it into the two stages that actually work, explains why, and
adds hugepages so the example covers every prerequisite.

This is independent of the NIC. The checks that fail take no interface or PCI
information and run before the NIC validation, so it affects every VPP
deployment, including the validated Mellanox, Intel E810, virtio, gVNIC and ENA
configurations. It was reproduced on VyOS 2026.03 both with an unsupported NIC
(Intel X710) and with a validated one (Red Hat virtio 1af4:1000, no override
set) — identical failure in both cases.

Worth noting for reviewers: such a commit is partial. system_option.py still
runs after vpp.py has failed, so the kernel options are applied and are what a
later save writes, while the set vpp ... statements stay behind in the
configuration session — neither applied nor saved, and lost on the reboot — even
though the overall result is reported as Commit failed. The documentation now
says so.

Other fixes included

• docs/vpp/requirements.md — added a short Kernel Configuration item.
  This is the page a first-time user reads, and it had no pointer to the kernel
  settings at all.
• docs/vpp/configuration/dataplane/cpu.md — documented the isolated-CPU
  requirement. The page never mentioned isolate-cpus, although
  verify_vpp_cpu_cores() rejects the commit when fewer CPUs are isolated than
  cpu-cores requests. This includes the default of cpu-cores 1, so every VPP
  deployment needs at least one isolated CPU before the dataplane can be enabled
  at all — test_01_vpp_basic relies on exactly that, never setting cpu-cores
  and still expecting main-core to be taken from the isolated set.
• docs/vpp/requirements.md — added the missing 1af4:1041 (virtio modern
  ID) row to the validated NIC table. It is present in SUPPORTED_PCI_IDS but
  was absent from the table.
• docs/vpp/requirements.md — corrected the allow-unsupported-nics note,
  which said the check is bypassed "for the specified devices". There are no
  specified devices: _is_device_allowed() returns True for every interface
  as soon as the option is set, including interfaces attached later. That
  wording looks like a leftover from the per-PCI-ID form originally proposed in
  T8315, which was merged as a single boolean.

Related Task(s)

Related PR(s)

Backport

Checklist:

• I have read the CONTRIBUTING document

---

Verified by building the docs locally with the pinned requirements.txt; the
three changed pages produce no Sphinx warnings.

https://claude.ai/code/session_016gXeKHVBq2N8qRAMQkrdM6

---

This is an automatic backport of pull request #2233 done by [Mergify](https://mergify.com).