VPP: Cisco's packet-processing stack running on commodity CPUs

This GitHub repository is a mirror, and the real one is at git.fd.io

The repository description says it plainly: this is a mirror of the VPP code base hosted at git.fd.io. That fact shapes everything about how you work with the project. The README refers to the FD.io website and to the VPP wiki for the full documentation, and it recommends the wiki page on pulling, building, running, hacking and pushing VPP code for step-by-step coverage. The pull request workflow lives in a different system, since the root has a .gitreview file, which is the configuration format used by Gerrit, the review server FD.io runs. Contributions to a mirror are not the path; the upstream project is where changes are made and reviewed, and this copy exists so the code is readable and searchable on a platform people already use.

The architectural claim is commodity hardware with a runtime data path

VPP is described as an extensible framework that provides out-of-the-box production quality switch and router functionality, and as the open source version of Cisco's Vector Packet Processing technology: a high-performance packet-processing stack that can run on commodity CPUs. The stated benefits are high performance, proven technology, modularity and flexibility, and a rich feature set. What distinguishes this design from a conventional kernel networking stack is where the work happens, in a user-space process that owns the data path rather than in the kernel's network stack. The consequence for an operator is that the packet processing path is separated from the operating system, which is what makes a single binary able to behave like a router rather than like a program that opens sockets.

The source tree separates the framework from the plugins and the protocol work

The directory layout in the README is the best map of the architecture. src/vppinfra is the VPP core library, src/vlib is the application library, and src/vlibapi is the VPP API library, with src/vpp holding the VPP application itself and src/vpp-api the application API bindings, plus src/vpp/api for bindings that are not yet relocated. The protocol and networking work lives in src/vnet, and bundled plugins have their own directory at src/plugins. On top of that sit src/vlibmemory for memory management and src/svm, a shared virtual memory allocation library used by the framework. The remaining directories are testing and tooling: src/tests holds standalone tests outside the main harness, src/vat is the VPP API test program, test/ contains the unit tests and the Python test harness, and src/examples holds example code.

One build script handles dependencies, build and install

The quick-start path on an existing Linux host is a single script, run from the project base directory by a non-privileged user with sudo access. It installs the system dependencies, builds VPP and then installs it.

./extras/vagrant/build.sh

If you intend to do development work rather than just try the software, the root Makefile offers a set of convenience targets, and running make with no arguments lists them.

make

The Makefile also shows the build knobs that matter. CCACHE_DIR points at a ccache directory under the build root so recompiles are cheap, the compiler defaults to clang when CC is left as the system default cc, and DPDK_CONFIG defaults to no-pci, which is the configuration that avoids requiring PCI passthrough hardware. A MINIMAL_STARTUP_CONF is generated with a Unix interactive section, a CLI socket at /run/vpp/cli.sock, an optional startup.vpp file if one exists, and a dpdk block populated from that DPDK_CONFIG value.

DPDK is the layer underneath, and its configuration is a decision

The dpdk/ directory at the root holds DPDK patches and build infrastructure, which tells you where the hardware abstraction comes from. The DPDK_CONFIG variable is the single most consequential setting for a new user, because it decides how the data path binds to the network interfaces, and its default is no-pci. The Makefile allows overriding it and also allows extra VPP configuration to be injected through EXTRA_VPP_CONFIG, which is how you append to the generated startup configuration. The root also carries build/ and build-root/ directories for build metadata and output, build-data/ for build metadata, docs/ for the Sphinx documentation, and a configure script at the top level.

Vagrant for a lab, FreeBSD packages for a quick install

Two alternative routes are documented. The extras/vagrant directory contains a VagrantFile and supporting scripts that bootstrap a working VPP inside a Vagrant-managed virtual machine, usable either for testing concepts or as a development platform for extending VPP. The README is clear about the caveat, that performance in a VM will never match bare metal, and that timing or performance sensitive work should use bare metal in addition to or instead of the VM. On FreeBSD, VPP is packaged in the ports system and binary packages are available.

# pkg install vpp

That path is the shortest route to a running system and is a reasonable way to evaluate whether VPP fits a problem before committing to a source build.

Apache-2.0 with a Cisco copyright and an upstream review process

The licence is Apache-2.0, with the LICENSE file at the repository root and the Makefile header carrying the standard Apache 2.0 notice and a 2021 Cisco and its affiliates copyright. The Apache licence choice matters for adopters, since it includes an express patent grant and requires that copyright and attribution notices be preserved, which many network vendors are comfortable with. The repository also carries a SECURITY.md, a MAINTAINERS file, a.clang-format and a.clang-tidy configuration, and an.editorconfig, which together describe a project with defined process rather than a loose collection of patches. The repository publishes no GitHub releases, and the last push was on 2026-10-19, so the upstream cadence is active even without tags here.

Editorial conclusion

VPP fits a network engineer who needs switch and router performance without custom silicon, or who wants to prototype a new packet-processing plugin against a mature framework with an existing API and test harness. It does not fit a general workload, and it is not appropriate on a host without the hugepage, pinned-CPU and NIC configuration that the DPDK layer requires. Verify first which DPDK configuration your environment supports, since the Makefile defaults to no-pci, and read the directory layout to understand whether the plugin you need lives in src/plugins, src/vlib or src/vnet before you plan your own code.

Frequently asked questions

Official sources

1. FDio/vpp on GitHub
2. Issues
3. License: Apache-2.0
4. README