summaryrefslogtreecommitdiff
path: root/docs/vpp/description.rst
diff options
context:
space:
mode:
authorYuriy Andamasov <yuriy@vyos.io>2026-05-06 20:42:32 +0300
committerYuriy Andamasov <yuriy@vyos.io>2026-05-06 20:42:32 +0300
commit5d6fa52b8985f8068314aba26878a1d7d5cb84e5 (patch)
tree99359ff282846e26b5c5fa2b9b176b35b172809f /docs/vpp/description.rst
parent631e454d674ad5111d2b56a6964ead461894a1f6 (diff)
downloadvyos-documentation-5d6fa52b8985f8068314aba26878a1d7d5cb84e5.tar.gz
vyos-documentation-5d6fa52b8985f8068314aba26878a1d7d5cb84e5.zip
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
Diffstat (limited to 'docs/vpp/description.rst')
-rw-r--r--docs/vpp/description.rst97
1 files changed, 0 insertions, 97 deletions
diff --git a/docs/vpp/description.rst b/docs/vpp/description.rst
deleted file mode 100644
index 8481bfe9..00000000
--- a/docs/vpp/description.rst
+++ /dev/null
@@ -1,97 +0,0 @@
-: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.