If we can find a SW P4 implementation for linux-generic... Do you mean that we should drop all existing pre-defined pattern matching rules for P4?
On 14 February 2017 at 18:40, Bill Fischofer <bill.fischo...@linaro.org> wrote: > While it is designed to be realized in HW, I believe P4 can also be > realized in SW. That would provide a generic means of having a unified > parser/classification strategy that is portable across all platforms, in > keeping with ODP's design goals. > > On Tue, Feb 14, 2017 at 11:29 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> P4 is certainly a good target for parser specification. That said, there >> are plenty of non-P4 HW that just need to be used from ODP. Another aspect >> is that P4 description cannot be translated to a non-programmable >> destination. One additional possibility is that current match rules may be >> translated to P4 one P4 capable devices. >> >> On 14 February 2017 at 02:30, Bill Fischofer <bill.fischo...@linaro.org> >> wrote: >> >>> 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 >>> >> >> >> >> -- >> [image: Linaro] <http://www.linaro.org/> >> François-Frédéric Ozog | *Director Linaro Networking Group* >> T: +33.67221.6485 >> francois.o...@linaro.org | Skype: ffozog >> >> > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
