On Wed, Apr 24, 2024 at 6:54 PM Robin Jarry <rja...@redhat.com> wrote: > > Robin Jarry, Apr 14, 2024 at 12:35: > > Jerin Jacob, Apr 06, 2024 at 01:11: > > > Great. > > > > > > You may consider improving and/or adding inbuilt nodes for generic > > > protocol processing. Furthermore, consider contributing on app/graph. > > > I think, most likely, you should be able to leverage app/graph. > > > > Thanks! I am definitely planning to upstream nodes into DPDK as much as > > possible. I still need to determine what is the correct level of data > > path node public API so that the nodes can be agnostic of the control > > plane implementation. > > Hey Jerin, > > while working on ARP support [1], I noticed that we need to have > configurability of nodes (or set of nodes to be more precise) from the > outside. But the nodes in the set also need to specify metadata that > they expect from other nodes to store in mbufs. > > For now, I have used a single dynamic field which I repurpose for every > node set depending on the use case [2]. However this raises a question: > how can we make it generic (and agnostic to the application) before > inclusion in lib/node? > > I would be glad to have your opinion on the subject.
Looking at the brouter[1] project, Based on my understanding it has following 1)Data plane code: IMO, Since it is generic and any consumers can reuse this code. IMO, We can make as generic and upstream to lib/node. 2)Control plane code: IMO, if you are willing, I will be glad to see it is hosted at https://www.dpdk.org/hosted-projects/ like pktgen. This may attract more developers for control plane code for brouter and show good reference of using DPDK graph library. I think, TB needs to approve for this. If you are OK, We can add this to one of TB meeting agenda. [1] https://github.com/rjarry/brouter/ > Cheers! > > [1] https://github.com/rjarry/brouter/commit/e05246f51b736821b6689d40 > [2] > https://github.com/rjarry/brouter/blob/main/modules/infra/datapath/br_mbuf.h >
