[PATCH v7 1/8] net/cpfl: add json parser for rte flow pattern rules

[Zhang, Qi Z]

> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Wednesday, September 27, 2023 3:04 AM
> To: Zhang, Yuying <yuying.zhang at intel.com>
> Cc: dev at dpdk.org; Zhang, Qi Z <qi.z.zhang at intel.com>; Wu, Jingjing
> <jingjing.wu at intel.com>; Xing, Beilei <beilei.xing at intel.com>; Qiao, Wenjing
> <wenjing.qiao at intel.com>
> Subject: Re: [PATCH v7 1/8] net/cpfl: add json parser for rte flow pattern rules
> 
> On Tue, 26 Sep 2023 18:16:56 +0000
> yuying.zhang at intel.com wrote:
> 
> > From: Wenjing Qiao <wenjing.qiao at intel.com>
> >
> > Add devargs "flow_parser" for rte flow json parser which depends on
> > jansson library.
> >
> > Example:
> >     -a ca:00.0,flow_parser="refpkg.json"
> >
> > Add json parser for rte flow pattern rules which can build rules that
> > maps from a set of rte flow items to hardware representations.
> >
> > The cpfl PMD supports utilizing a JSON configuration file to translate
> > rte flow tokens into low level hardware resources. The JSON
> > configuration file is provided by the hardware vendor and is intended
> > to work exclusively with a specific P4 pipeline configuration, which
> > must be compiled and programmed into the hardware.
> >
> > The format of the JSON file strictly follows the internal
> > specifications of the hardware vendor and is not meant to be modified
> > directly by users.
> >
> > Signed-off-by: Wenjing Qiao <wenjing.qiao at intel.com>
> 
> It is good to see the code is now using the same JSON parser as elsewhere in
> DPDK.
> 
> How does this interact with the P4 work done by Cristian, is this part of that?
> Is this treated as opaque firmware?

This solution is not related with p4 support.

Though the device is configured with P4, but there is no P4 aware interface be leveraged here.
The JSON file direct PMD to translate the  rte_flow fixed pattern / action into low level hardware configure directly. 

The purpose of introducing this solution is to facilitate a smooth migration for certain customers who wish to transition their existing applications  from other NICs to IPU. 
But, of cause this approach have limitations for customers to fully leverage the capabilities of the P4 device, as not all offloading features can be mapped into fixed functions.

The solution based on Cristian's patch will be enabled in a later release. Both solutions will be available exclusively at runtime, depending on the user's intention.

> Why is it driver specific? DPDK P4 support needs to be vendor neutral to
> acceptable.

Even with the P4 solution, the PMD must determine how to map P4 tables and actions into low-level hardware representations. This knowledge is generated by the compiler, and there are a couple of options to enable the PMD to access this knowledge:

1. Embedding this knowledge into a storage space on the hardware, allowing the PMD to learn from the hardware through internal firmware APIs.
2. Storing the knowledge in the file system and having the PMD load this file using devargs.

But, these options are vendor-specific in nature.

Regards
Qi