|
reboot (#2233)
* docs: vpp: document that kernel prerequisites need their own commit and reboot
VPP depends on hugepages and, since T8460, on isolated CPUs. Both are
configured under "system option kernel", take effect only after a
reboot, and are validated by VPP 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 - the VPP part is always
rejected with "Not enough free memory to start VPP!" or "Not enough
isolated CPU cores available", both of which point back at the very
command the user just issued.
This is independent of the NIC: the checks that fail take no interface
or PCI information and run before the NIC validation. It was reproduced
both with an unsupported NIC and with a validated one.
Such a commit is also partial: the "system option kernel" part is
applied even though the commit is reported as failed, while the
"set vpp ..." statements are discarded and have to be re-entered after
the reboot.
The "Optimal Configuration Example" showed exactly this failing
one-shot form, mixing "set system option kernel ..." and "set vpp
settings ..." in a single block. Split it into the two stages that
actually work and state why, and add hugepages to it so the example
covers every prerequisite.
Also:
* add a short "Kernel Configuration" item to the requirements page,
which is what a first-time user reads and which had no pointer to
the kernel settings at all
* document the isolated-CPU requirement on the cpu-cores page, which
did not mention "isolate-cpus"
* add the missing 1af4:1041 (virtio modern ID) row to the validated
NIC table - it is present in SUPPORTED_PCI_IDS but was absent here
* correct 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 is a leftover from the per-PCI-ID form originally
proposed in T8315, which was merged as a single boolean.
Verified by building the docs; the three changed pages produce no
Sphinx warnings.
Claude-Session: https://claude.ai/code/session_01EQsKVSw5hhDu7jPq1YzQvj
* docs: vpp: correct what a failed VPP commit leaves behind
Two corrections to the pages added earlier in this PR.
The partial-commit note claimed that the "set vpp ..." statements are
"discarded". They are not. Verified on VyOS 2026.03: after the commit
fails, "compare" still shows them staged in the configuration session.
[vpp settings]
+ resource-allocation {
+ memory {
+ main-heap-size "6G"
+ }
+ }
What actually happens is worse than the previous wording suggested and
worth stating precisely: the statements are neither applied nor written
by "save", because "save" writes the running configuration - which
"system_option.py" has already updated with the kernel options while the
VPP part was rejected. The session does not survive the reboot, so the
VPP statements are lost there rather than at commit time.
The isolated-CPU requirement was also described as if it only applied
once "cpu-cores" is raised. It applies at the default of "cpu-cores 1"
as well: verify_vpp_cpu_cores() rejects the commit whenever fewer CPUs
are isolated than requested, and VPP takes its main core from the
isolated set. The project's own test_01_vpp_basic relies on this - it
never sets "cpu-cores" and still expects "main-core" to be taken from
/sys/devices/system/cpu/isolated. Without this, a reader doing a minimal
setup would conclude that CPU isolation is optional for them.
Claude-Session: https://claude.ai/code/session_016gXeKHVBq2N8qRAMQkrdM6
|
