Difference between revisions of "Project Proposals/odp4vpp"
(→Description) |
|||
(One intermediate revision by the same user not shown) | |||
Line 28: | Line 28: | ||
== Scope == | == Scope == | ||
− | + | To produce plugin(s) to vpp to enable vpp to take advantage of ODP managed hardware. | |
− | + | These plugin(s) may provide additional graph nodes, rewire the VPP graph to take advantage of those graph nodes, etc via the normal vpp plugin mechanisms. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
== Initial Committers == | == Initial Committers == | ||
Line 52: | Line 42: | ||
Yann Kalemkarian, yann.kalemkarian@kalray.com | Yann Kalemkarian, yann.kalemkarian@kalray.com | ||
+ | |||
+ | Sachin Saxena, sachin.saxena@linaro.org | ||
+ | |||
Latest revision as of 14:16, 28 February 2017
Contents
Name
odp4vpp
Project Contact Name and Email
François-Frédéric Ozog, francois.ozog@linaro.org
Repository Name
odp4vpp
Description
odp4vpp project aims to provide VPP with an additional vnet device based on OpenDataPlane (ODP is similar yet different from DPDK), with provisions for hardware acceleration of packet paths. It envisions three deployment scenarios:
- Server + NICs
- Systems on a Chip
- SmartNIC with low to very high core count
- Note: OpenDataPlane [1] allow applications to build Software Defined Data Planes which means that the actual data paths can be hardware only. As an example, a packet may be autonomously received on one port, routed to a destination, tunneled in IPsec by the hardware. ODP API calls are just programming hardware blocks such as classifiers, packet schedulers, IPsec, traffic mamanager (shaping)... DPDK is a Softawre Data Plane that allow applications to access NICs in a high performance manner. When there is no hardware blocks available, software emulated blocks (classifier, scheduler...) are used: ODP then operates as a Software Dataplane, i.e. it is behaving very similarly to DPDK.
ODP has been ported to very different system architectures where packet buffers are hardware managed, CPU cores with private memory (non NUMA architectures similar to GPUs) so it is expected that vlib_buffer_t to/from odp_packet_t mapping become extremely efficient.
It is expected that ODP behave as packet input and packet sink.
Scope
To produce plugin(s) to vpp to enable vpp to take advantage of ODP managed hardware.
These plugin(s) may provide additional graph nodes, rewire the VPP graph to take advantage of those graph nodes, etc via the normal vpp plugin mechanisms.
Initial Committers
Committers: Sreejith Surendran Nair , srsurend@cisco.com
Bill Fischofer , bill.fischofer@linaro.org
Maciej Czekaj, mjc@semihalf.com
Yann Kalemkarian, yann.kalemkarian@kalray.com
Sachin Saxena, sachin.saxena@linaro.org
Contributors:
Andriy Berestovsky (aber@semihalf.com)
Vendor Neutral
The project is technically sponsored by Linaro on behalf of its members which include a number of silicon vendors and equipment providers.
Meets Board Policy (including IPR, being within Board defined Scope etc)
Meets board policy as expressed in Technical Community Charter and IP Policy
Administrata
- Request for Project proposal consideration
- Email: (place link to email to TSC proposing project, this can be obtained from TSC Archives
- Date: starting second week January 2017