-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Wednesday, September 27, 2023 3:04 AM
To: Zhang, Yuying <redacted>
Cc: dev@dpdk.org; Zhang, Qi Z <redacted>; Wu, Jingjing
[off-list ref]; Xing, Beilei [off-list ref]; Qiao, Wenjing
[off-list ref]
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@intel.com wrote:

quoted

From: Wenjing Qiao <redacted>

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 <redacted>

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