vpp - Vector Packet Processing

Age	Commit message (Expand)	Author	Files	Lines
2018-06-04	flow:add enabled hw format function	Eyal Bari	2	-0/+25
2018-05-17	flow:redirect to node	Eyal Bari	1	-0/+8
2018-05-10	vnet: device flow offload infra	Damjan Marion	3	-0/+818
2018-05-04	Flow: Rename IPFIX exporter.	Ole Troan	8	-2572/+0
2018-02-07	Refactor vlib_buffer flags	Damjan Marion	1	-1/+1
2018-01-23	VPPAPIGEN: vppapigen replacement in Python PLY.	Ole Troan	1	-1/+1
2018-01-11	api: remove transport specific code from handlers	Florin Coras	1	-15/+15
2018-01-09	api: refactor vlibmemory	Florin Coras	1	-5/+4
2018-01-08	NAT64: IPFix (VPP-1106)	Matus Fabian	1	-1/+5
2017-11-26	VPP-252 Coding standards cleanup - vnet/vnet/flow	Swarup Nayak	6	-563/+663
2017-10-09	vppapigen: support per-file (major,minor,patch) version stamps	Dave Barach	1	-0/+2
2017-05-30	Flowprobe: Stateful flows and IPv6, L4 recording	Ole Troan	4	-11/+17
2017-05-24	ipfix: make IPFIX work for all skip_n_vectors values (VPP-204)	Juraj Sloboda	1	-22/+23
2017-04-25	"autoreply" flag: autogenerate standard xxx_reply_t messages	Dave Barach	1	-29/+3
2017-04-21	CGN: IPFIX logging	Matus Fabian	1	-1/+2
2017-03-01	VPP-598: tcp stack initial commit	Dave Barach	1	-1/+1
2017-01-25	API refactoring : flow	Pavel Kotucek	2	-0/+570
2016-12-28	Reorganize source tree to use single autotools instance	Damjan Marion	6	-0/+1915

NFV Service Density ------------------- Network Function Virtualization (NFV) service density tests focus on measuring total per server throughput at varied NFV service “packing” densities with vswitch providing host dataplane. The goal is to compare and contrast performance of a shared vswitch for different network topologies and virtualization technologies, and their impact on vswitch performance and efficiency in a range of NFV service configurations. Each NFV service instance consists of a set of Network Functions (NFs), running in VMs (VNFs) or in Containers (CNFs), that are connected into a virtual network topology using VPP vswitch running in Linux user-mode. Multiple service instances share the vswitch that in turn provides per service chain forwarding context(s). In order to provide a most complete picture, each network topology and service configuration is tested in different service density setups by varying two parameters: - Number of service instances (e.g. 1, 2, 4, 6, 8, 10). - Number of NFs per service instance (e.g. 1, 2, 4, 6, 8, 10). Implementation of NFV service density tests in |csit-release| is using two NF applications: - VNF: VPP of the same version as vswitch running in KVM VM, configured with /8 IPv4 prefix routing. - CNF: VPP of the same version as vswitch running in Docker Container, configured with /8 IPv4 prefix routing. Tests are designed such that in all tested cases VPP vswitch is the most stressed application, as for each flow vswitch is processing each packet multiple times, whereas VNFs and CNFs process each packets only once. To that end, all VNFs and CNFs are allocated enough resources to not become a bottleneck. Service Configurations ~~~~~~~~~~~~~~~~~~~~~~ Following NFV network topologies and configurations are tested: - VNF Service Chains (VSC) with L2 vswitch - *Network Topology*: Sets of VNFs dual-homed to VPP vswitch over virtio-vhost links. Each set belongs to separate service instance. - *Network Configuration*: VPP L2 bridge-domain contexts form logical service chains of VNF sets and connect each chain to physical interfaces. - CNF Service Chains (CSC) with L2 vswitch - *Network Topology*: Sets of CNFs dual-homed to VPP vswitch over memif links. Each set belongs to separate service instance. - *Network Configuration*: VPP L2 bridge-domain contexts form logical service chains of CNF sets and connect each chain to physical interfaces. - CNF Service Pipelines (CSP) with L2 vswitch - *Network Topology*: Sets of CNFs connected into pipelines over a series of memif links, with edge CNFs single-homed to VPP vswitch over memif links. Each set belongs to separate service instance. - *Network Configuration*: VPP L2 bridge-domain contexts connect each CNF pipeline to physical interfaces. Thread-to-Core Mapping ~~~~~~~~~~~~~~~~~~~~~~ CSIT defines specific ratios for mapping software threads of vswitch and VNFs/CNFs to physical cores, with separate ratios defined for main control threads and data-plane threads. In |csit-release| NFV service density tests run on Intel Xeon testbeds with Intel Hyper-Threading enabled, so each physical core is associated with a pair of sibling logical cores corresponding to the hyper-threads. |csit-release| executes tests with the following software thread to physical core mapping ratios: - vSwitch - Data-plane on single core - (main:core) = (1:1) => 1mt1c - 1 main thread on 1 core. - (data:core) = (1:1) => 2dt1c - 2 Data-plane Threads on 1 Core. - Data-plane on two cores - (main:core) = (1:1) => 1mt1c - 1 Main Thread on 1 Core. - (data:core) = (1:2) => 4dt2c - 4 Data-plane Threads on 2 Cores. - VNF and CNF - Data-plane on single core - (main:core) = (2:1) => 2mt1c - 2 Main Threads on 1 Core, 1 Thread per NF, core shared between two NFs. - (data:core) = (1:1) => 2dt1c - 2 Data-plane Threads on 1 Core per NF. - Data-plane on single logical core (Two NFs per physical core) - (main:core) = (2:1) => 2mt1c - 2 Main Threads on 1 Core, 1 Thread per NF, core shared between two NFs. - (data:core) = (2:1) => 2dt1c - 2 Data-plane Threads on 1 Core, 1 Thread per NF, core shared between two NFs. Maximum tested service densities are limited by a number of physical cores per NUMA. |csit-release| allocates cores within NUMA0. Support for multi NUMA tests is to be added in future release.