RE: [RFC PATCH 0/3] add featur arc in rte_graph

[Kiran Kumar Kokkilagadda <kirankumark@marvell.com>]

> -----Original Message-----
> From: Nitin Saxena <nsaxena@marvell.com>
> Sent: Saturday, September 7, 2024 12:35 PM
> To: Jerin Jacob <jerinj@marvell.com>; Kiran Kumar Kokkilagadda
> <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Zhirun Yan <yanzhirun_163@163.com>
> Cc: dev@dpdk.org
> Subject: [RFC PATCH 0/3] add featur arc in rte_graph
> 
> Feature arc represents an ordered list of features/protocols at a given
> networking layer. It is a high level abstraction to connect various rte_graph
> nodes, as feature nodes, and allow packets steering across these nodes in a
> generic manner.
> 
> Features (or feature nodes) are nodes which handles partial or complete
> handling of a protocol in fast path. Like ipv4-rewrite node, which adds rewrite
> data to an outgoing IPv4 packet.
> 
> However in above example, outgoing interface(say "eth0") may have
> outbound IPsec policy enabled, hence packets must be steered from ipv4-
> rewrite node to ipsec-outbound-policy node for outbound IPsec policy
> lookup. On the other hand, packets routed to another interface
> (eth1) will not be sent to ipsec-outbound-policy node as IPsec feature is
> disabled on eth1. Feature-arc allows rte_graph applications to manage such
> constraints easily
> 
> Feature arc abstraction allows rte_graph based application to
> 
> 1. Seamlessly steer packets across feature nodes based on wheter feature is
> enabled or disabled on an interface. Features enabled on one interface may
> not be enabled on another interface with in a same feature arc.
> 
> 2. Allow enabling/disabling of features on an interface at runtime, so that if a
> feature is disabled, packets associated with that interface won't be steered to
> corresponding feature node.
> 
> 3. Provides mechanism to hook custom/user-defined nodes to a feature node
> and allow packet steering from feature node to custom node without changing
> former's fast path function
> 
> 4. Allow expressing features in a particular sequential order so that packets are
> steered in an ordered way across nodes in fast path. For
> eg: if IPsec and IPv4 features are enabled on an ingress interface, packets must
> be sent to IPsec inbound policy node first and then to ipv4 lookup node.
> 
> This patch series adds feature arc library in rte_graph and also adds "ipv4-
> output" feature arc handling in "ipv4-rewrite" node.
> 
> Nitin Saxena (3):
>   graph: add feature arc support
>   graph: add feature arc option in graph create
>   graph: add IPv4 output feature arc
> 
>  lib/graph/graph.c                        |   1 +
>  lib/graph/graph_feature_arc.c            | 959 +++++++++++++++++++++++
>  lib/graph/graph_populate.c               |   7 +-
>  lib/graph/graph_private.h                |   3 +
>  lib/graph/meson.build                    |   2 +
>  lib/graph/node.c                         |   2 +
>  lib/graph/rte_graph.h                    |   3 +
>  lib/graph/rte_graph_feature_arc.h        | 373 +++++++++
>  lib/graph/rte_graph_feature_arc_worker.h | 548 +++++++++++++
>  lib/graph/version.map                    |  17 +
>  lib/node/ip4_rewrite.c                   | 476 ++++++++---
>  lib/node/ip4_rewrite_priv.h              |   9 +-
>  lib/node/node_private.h                  |  19 +-
>  lib/node/rte_node_ip4_api.h              |   3 +
>  14 files changed, 2325 insertions(+), 97 deletions(-)  create mode 100644
> lib/graph/graph_feature_arc.c  create mode 100644
> lib/graph/rte_graph_feature_arc.h  create mode 100644
> lib/graph/rte_graph_feature_arc_worker.h

Could you add unit test for these new APIs?

> 
> --
> 2.43.0