feat: flip swap mechanism — MD as primary, RST as override (Phase 1)

This is the first of three phases inverting the per-page swap mechanism
so MD becomes the canonical primary and RST becomes the rare override.

Phase 1 — file renames + conf.py exclude_patterns flip only:
- Rename docs/**/md-<stem>.md to docs/**/<stem>.md (drop md- prefix)
  for all 254 stems previously listed in docs/_swap.txt
- Rename docs/**/<stem>.rst to docs/**/rst-<stem>.rst (add rst- prefix)
  for the same 254 stems
- Repurpose docs/_swap.txt as docs/_rst_overrides.txt; initially empty
  comment-only since no pages need the RST fallback right now
- conf.py exclude_patterns flipped: rst-*.rst is now excluded by default
  instead of md-*.md
- conf.py runtime-artifact references updated to _rst_override_state.json
  and _md_exclude.txt (Phase 2 will rewrite swap_sources.py to produce
  these names; for now no swap script runs because overrides list is empty)

Phase 2 (next commit on this branch) will rewrite scripts/swap_sources.py
with inverted rename direction, delete scripts/import_myst.py + tests, and
update tests/test_swap_sources.py for the new semantics.

Phase 3 will be the cleanup pass and ready-for-review flip.

Generated by robots https://vyos.io

1 files changed, 87 insertions, 0 deletions

diff --git a/docs/vpp/description.md b/docs/vpp/description.md
new file mode 100644
index 00000000..b6899564
--- /dev/null
+++ b/docs/vpp/description.md
@@ -0,0 +1,87 @@
+---
+lastproofread: '2026-02-16'
+---
+
+(vpp-description)=
+
+```{include} /_include/need_improvement.txt
+```
+
+
+# VPP Dataplane Description
+
+## What is VPP in VyOS?
+
+VyOS supports two packet forwarding dataplanes:
+- **Linux kernel dataplane** (traditional)
+- **Vector Packet Processor (VPP) dataplane** (optional)
+
+VPP is a high-performance user space packet processor that improves
+throughput for demanding network workloads.
+
+## Key Benefits
+
+**Performance Improvement**
+
+VPP uses vector-based packet processing instead of one-by-one handling,
+delivering:
+- **Higher throughput** compared to kernel forwarding.
+- **Lower and more consistent latency** for time-sensitive applications.
+- **Linear scaling** with additional CPU cores.
+
+**VyOS Hybrid Integration**
+
+VyOS supports both dataplanes simultaneously, providing:
+- **Cross-dataplane forwarding**: Traffic can flow between the VPP dataplane
+  and kernel interfaces seamlessly.
+- **Transparent configuration**: Same CLI commands and most services work
+  regardless of dataplane.
+- **Gradual migration**: Enable VPP on high-traffic interfaces while keeping
+  others on kernel.
+
+## When to Use VPP
+
+**Consider VPP if you have:**
+- High-throughput requirements
+- Latency-sensitive applications requiring consistent performance
+
+**Stay with kernel dataplane if you have:**
+- Low to moderate traffic volumes
+- No latency-sensitive workloads
+- Applications requiring specific features not supported by VPP Dataplane
+
+## Packet Processing Integration
+
+VPP Dataplane integration minimizes configuration changes. Features in the
+kernel dataplane continue to operate there. VPP Dataplane only handles packet
+forwarding for interfaces explicitly assigned to it.
+
+Traffic flow examples between VPP and kernel dataplane interfaces:
+
+```{image} /_static/images/vpp/vyos_vpp_integration.svg
+:align: center
+```
+
+
+### Green path
+
+Traffic between two VPP interfaces stays within VPP for maximum performance
+and can use only VPP dataplane features.
+
+### Blue path
+
+Traffic between a VPP interface and a kernel interface is processed by both
+dataplanes and can use features from both.
+
+**Note:** This path has slower performance than pure VPP or pure kernel
+forwarding because packets traverse both dataplanes.
+
+### Red path
+
+Traffic between two kernel interfaces stays within the kernel dataplane without
+VPP acceleration. This is the traditional VyOS dataplane operation.
+
+## CLI Integration
+
+VyOS CLI commands work with both dataplanes. Use the same commands to
+configure interfaces, routing, and other features regardless of the dataplane.