Re: [RFC] P4 enablement in DPDK

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Wed, 18 Apr 2018 18:22:01 +0100
> From: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> To: dev@dpdk.org
> CC: dan.daly@intel.com
> Subject: [dpdk-dev] [RFC] P4 enablement in DPDK
> X-Mailer: git-send-email 2.7.4
> 
> P4 is a language for programming the data plane of network devices [1]. The P4
> language is developed by p4.org which is joining ONF and Linux Foundation [2].
> 
> This API provides a way to program P4 capable devices through DPDK. The purpose
> of this API is to enable P4 compilers [3] to generate high performance DPDK code
> out of P4 programs.
> 
> The main advantage of this approach is that P4 enablement of network devices can
> be done through DPDK in a unified way:
> 
>    1. This API serves as the interface between the P4 compiler front-end (target
>       independent) and the P4 compiler backe-ends (target specific).
> 
>    2. Device vendors develop their device drivers as part of DPDK by
>       implementing this API. The device driver is agostic of being called by the
>       P4 front-end. The device driver serves as the P4 compiler taget specific
>       back-end.
> 
>    3. The P4 compiler front-end is target independent. The amount of C code it
>       generates is minimized by calling this API directly for every P4 feature
>       as opposed to vendor-specific free-style C code generation.
> 
> This API introduces a pipeline device (PDEV) by using a similar approach to the
> existing ethdev and eventdev DPDK device-like APIs implemented by the DPDK Poll
> Mode Drivers (PMDs). Main features:
> 
>    1. Discovery of built-in pipeline devices and their capabilities.
> 
>    2. Creation of new pipelines out of input ports, output ports, tables and
>       actions.
> 
>    3. Registration of packet protocol header and meta-data fields.
> 
>    4. Action definition for input ports, output ports and tables.
> 
>    5. Pipeline run-time API for table population, statistics read, etc.
> 
> This API targets P4 capable devices such as NICs, FPGAs, NPUs, ASICs, etc, as
> well as CPUs. Let’s remember that the first P in P4 stands for Programmable, and
> the CPUs are arguably the most programmable devices. The implementation for the
> CPU SW target is expected to use the DPDK Packet Framework libraries such as
> librte_pipeline, librte_port, librte_table with some expected but moderate API
> and implementation adjustments.
> 
> Links:
> 
>    [1] P4-16 language specification:
>        https://p4lang.github.io/p4-spec/docs/P4-16-v1.0.0-spec.pdf
> 
>    [2] p4.org to join ONF and LF: https://p4.org/p4/onward-and-upward.html
> 
>    [3] p4c: https://github.com/p4lang/p4c
> 
> Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
>  lib/librte_pipeline/rte_pdev.h        | 1654 +++++++++++++++++++++++++++++++++
>  lib/librte_pipeline/rte_pdev_driver.h |  283 ++++++

How about moving this as separate library(pipeline dev) with driver(plugin) interface
and librte_pipeline based API being used as one plugin/driver. This will enable us
to hook another HW based or HW-SW combination of plugins in future.

Eventdev has capability to create pipeline that can be add in future
as plugin/driver. The code to deal with rte_tm etc in plugin, you can
make it as common code in the library. So that new plugin can be created based eventdev
+ other building blocks such as rte_tm.


/Jerin