Re: [EXTERNAL] Re: [RFC PATCH 0/3] add feature arc in rte_graph

["Robin Jarry" <rjarry@redhat.com>]

Hi folks,

David Marchand, Oct 16, 2024 at 11:24:
> On Mon, Oct 14, 2024 at 1:12 PM Nitin Saxena <nsaxena@marvell.com> wrote:
>> I had pushed non RFC patch series before -rc1 date (11th oct).
>> We have an ABI change in this patch series https://patches.dpdk.org/project/dpdk/patch/20241010133111.2764712-3-nsaxena@marvell.com/
>> Could you help merge this patch series in rc2 otherwise it has to wait for next LTS
>
> Just read through the series, I am not confident with this addition.
> It requires a lot of changes in the node code for supporting it, where
> it should be something handled in/facilitated by the graph library
> itself.

As far as I can tell, it will be very complicated (if not impossible) to 
determine in a generic manner whether a packet must be steered towards 
a sub tree or not. The decision *must* come from the originating node in 
some way or another.

> I did not read much from Robin or Christophe who have been writing
> more node code than me.
> I would prefer their opinion before going forward.

This series is indeed very dense. I like the concept of having 
extensible sub trees in the graph but it feels like the implementation 
is more complex than it should be.

Lacking of another solution, we went for a naive approach in grout. 
Basically, some nodes have undefined next nodes which are extended using 
a dedicated API.

https://github.com/DPDK/grout/blob/v0.2/modules/infra/datapath/eth_input.c#L23-L31

This API can be used by other nodes to attach themselves to these 
extensible nodes:

https://github.com/DPDK/grout/blob/v0.2/modules/ip/datapath/arp_input.c#L143
https://github.com/DPDK/grout/blob/v0.2/modules/ip/datapath/ip_input.c#L124
https://github.com/DPDK/grout/blob/v0.2/modules/ip6/datapath/ip6_input.c#L122

After which, the extensible nodes can steer the packets towards the 
correct downstream edge based on the dedicated classifier field:

https://github.com/DPDK/grout/blob/v0.2/modules/infra/datapath/eth_input.c#L79

Obviously, this does not natively support a per-interface sub tree 
traversal, but it can be done in the originating node based on packet 
private context data.

This raises a more important question: how can we standardize the way 
private application data is passed from node to node? And how could we 
enforce this declaratively in the node register API?

Do you think we could find some middle ground that would not require 
such extensive changes?

Cheers,
Robin