> -----Original Message-----
> From: Stephen Hemminger <step...@networkplumber.org>
> Sent: Wednesday, September 27, 2023 3:04 AM
> To: Zhang, Yuying <yuying.zh...@intel.com>
> Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zh...@intel.com>; Wu, Jingjing
> <jingjing...@intel.com>; Xing, Beilei <beilei.x...@intel.com>; Qiao, Wenjing
> <wenjing.q...@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.zh...@intel.com wrote:
>
> > From: Wenjing Qiao <wenjing.q...@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.q...@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
