While we can extend the current ODP classifier by adding additional PMR terms, I think a better long-term strategy is to adopt P4 as a generalized parser adjunct to better map to future flexible HW platforms (FPGA or SoC) that will be implementing native P4 capabilities as P4 continues to gain industry traction.
If you look at the current P4 high level architecture [1] the manufacturer-supplied "Dataplane Runtime" in that diagram can be viewed as ODP + P4 runtime extensions (or P4 runtime + ODP adapters). This is especially attractive since the P4-16 level of the language has been modularized to better fit the platform independent / platform dependent partitioning that ODP has been using. The advantage for ODP is not only do we get a flexible parser (plus a programmatic pipeline) that maps well to HW implementations, but that applications can freely define their own arbitrary packet header structures (or select from an existing library of such structures) without us having to adjust the ODP API to accommodate each new term or field variant that may arise. Beyond this, I think we may well discover that ODP+P4 provides the scaffolding we need to do true generalized accelerator pipelining that we've been trying to realize. --- [1] See Figure 2 of http://p4.org/wp-content/uploads/2016/12/P4_16-prerelease-Dec_16.html On Mon, Feb 13, 2017 at 2:19 PM, Francois Ozog <francois.o...@linaro.org> wrote: > Hi, > > as I was checking ODP Classification rules, I spotted a few possible > extensions: > > - global options: > . apply the defined rule on the last IP header > > - additional rules > . rule on SCTP port > . rule on IPsec SPI > . rule on GTP TEID > > Can those extensions be implemented by current hardware ? close to hit > market hardware ? > > What are other possibilities? > > What are the effects of NFV/Cloud encapsulations (VXLANs, Geneve...) ? > > Cordially, > > FF
