From 323f8b4b4bbbf2545991e1eb4dc5fa5f8def37e1 Mon Sep 17 00:00:00 2001 From: Yuriy Andamasov Date: Wed, 29 Apr 2026 06:50:50 +0300 Subject: fix: re-import 4 canary md-*.md files with xref label fixes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Re-imports the dash-form-corrected versions of: - contributing/md-development.md (added (coding-guidelines)= anchor) - operation/md-upgrade-recovery.md (3 ref renames: how_it_works / cancelling_recovery -> dash form) - vpp/configuration/dataplane/md-buffers.md (vpp_config_dataplane_physmem -> vpp-config-dataplane-physmem) - vpp/configuration/dataplane/md-unix.md (vpp_config_dataplane_interface_rx_mode -> vpp-config-dataplane-interface-rx-mode) Source: origin/myst/current commit 59fbe3ea. Verified locally: clean swap-build no longer reports any of the 5 target labels (1 of 6 — vpp-config-hugepages — remains because system.md isn't in the canary swap list; that anchor lives there). 🤖 Generated by [robots](https://vyos.io) --- docs/vpp/configuration/dataplane/md-buffers.md | 90 -------------------------- docs/vpp/configuration/dataplane/md-unix.md | 54 ---------------- 2 files changed, 144 deletions(-) delete mode 100644 docs/vpp/configuration/dataplane/md-buffers.md delete mode 100644 docs/vpp/configuration/dataplane/md-unix.md (limited to 'docs/vpp') diff --git a/docs/vpp/configuration/dataplane/md-buffers.md b/docs/vpp/configuration/dataplane/md-buffers.md deleted file mode 100644 index 80f2f23c..00000000 --- a/docs/vpp/configuration/dataplane/md-buffers.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -lastproofread: '2026-02-23' ---- - -(vpp-config-dataplane-buffers)= - -```{include} /_include/need_improvement.txt -``` - -# VPP Dataplane Buffers Configuration - -Buffers are essential for handling network packets efficiently. Proper -configuration enhances performance and reliability, and is mandatory for -VPP to work. Buffers temporarily store packets during processing. Therefore, -their configuration must be in sync with NIC configuration, CPU threads, and -overall system resources. - -:::{important} -VPP buffers are allocated from the physical memory pool (`physmem`). The -total amount of memory available for buffer allocation is controlled by the -`physmem-max-size` setting, while the buffer configuration parameters -below control how that memory is used for buffer allocation. - -See {ref}`VPP Physical Memory Configuration ` -for details on configuring `physmem`. -::: - -## Buffer Configuration Parameters - -The following parameters can be configured for VPP buffers: - -### buffers-per-numa -Number of buffers allocated per NUMA node. This setting optimizes -memory access patterns for multi-CPU systems. - -Typically, you need to tune this value if: -- The system has many interfaces -- NICs have many queues -- NICs have large descriptor sizes - -Set this value carefully to balance memory usage and performance. -```{cfgcmd} set vpp settings resource-allocation buffers buffers-per-numa \ -``` -The common approach for the calculation is to use the formula: -```none -buffers-per-numa = (num-rx-queues * num-rx-desc) + (num-tx-queues * num-tx-desc) -``` -Calculate this formula for each NIC and sum the results. Multiply the -total by 2.5 to get the minimum recommended value for -`buffers-per-numa`. - -Avoid setting this value too low to prevent packet drops. - -### data-size -This value sets how much payload data can be stored in a single buffer -allocated by VPP. Larger values reduce buffer chains for large packets, -while smaller values conserve memory for environments handling mostly -small packets. -```{cfgcmd} set vpp settings resource-allocation buffers data-size \ -``` -Optimal size depends on the typical packet size in your network. If -unsure, use the largest MTU in your network plus overhead (for example, -128 bytes). - -### page-size -A memory pages type used for buffer allocation. Common values are 4K, 2M, or 1G. - -Use page sizes configured in your system settings. -```{cfgcmd} set vpp settings resource-allocation buffers page-size \ -``` - -## Potential Issues and Troubleshooting - -Improper buffer configuration can lead to issues such as: - -- Increased latency and packet loss -- Inefficient CPU utilization -- Interface initialization failures - -Indicators of such issues are: - -- Errors during interfaces initialization in VPP logs -- Packet drops observed in VPP statistics - -To troubleshoot buffer-related issues, consider the following steps: - -- Review VPP logs for errors related to buffer allocation. Look for - error `-5` messages. -- Tune available buffers by adjusting the `buffers-per-numa` and - `data-size` parameters. diff --git a/docs/vpp/configuration/dataplane/md-unix.md b/docs/vpp/configuration/dataplane/md-unix.md deleted file mode 100644 index ba89d650..00000000 --- a/docs/vpp/configuration/dataplane/md-unix.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -lastproofread: '2026-02-27' ---- - -(vpp-config-dataplane-unix)= - -```{include} /_include/need_improvement.txt -``` - -# VPP Unix Dataplane Configuration -The UNIX configuration section is used to control VPP's interaction -with the underlying operating system, including operations scheduling. - -VPP relies on the polling mechanism to efficiently manage I/O operations -and system events. By default VPP continuously polls for events, which -leads to permanent 100% CPU usage by all cores assigned to VPP dataplane. -This is optimal for performance, but may not be desirable in all -environments, especially where power consumption is a concern or where VPP -is running inside a hypervisor, especially if the VM has burstable -thresholds and CPU usage limits. - -To mitigate this, VPP provides a configurable polling delay that allows -reducing CPU usage by introducing a delay between polling cycles. This -introduces a trade-off between CPU usage and latency, as longer delays -can lead to increased latency in processing events. - -You can configure the polling delay using the following command in the -VyOS CLI: -```{cfgcmd} set vpp settings poll-sleep-usec \ -``` - -Sets the polling delay in microseconds. A value of 0 means no delay -(default), while higher values introduce a delay between polling cycles. - -## Troubleshooting - -Setting the polling delay too high can lead to increased latency and -reduced performance, as VPP may not respond to events as quickly. -Conversely, setting it too low may result in high CPU usage, which can be -problematic in resource-constrained environments. - -Symptoms of improper configuration may include: - -- Increased latency in packet processing -- Higher CPU usage than expected -- Packets lost due to buffer overruns - -If you do not need to reduce CPU usage, it is recommended to leave the -polling delay at its default value of 0 for optimal performance. - -If you need to reduce CPU usage, you may also consider using `interrupt` or -`adaptive` {ref}`DPDK driver modes `, -which can provide a balance between performance and resource utilization -without affecting polling behavior. -- cgit v1.2.3