Hi folks,
David Marchand, Oct 16, 2024 at 11:24:
On Mon, Oct 14, 2024 at 1:12 PM Nitin Saxena <nsax...@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-nsax...@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
