Hi Nitin, all,
Nitin Saxena, Oct 17, 2024 at 09:03:
Hi Robin/David and all,
We realized the feature arc patch series is difficult to understand as
a new concept. Our objectives are following with feature arc changes
1. Allow reusability of standard DPDK nodes (defined in lib/nodes/*)
with out-of-tree applications (like grout). Currently out-of-tree
graph applications are duplicating standard nodes but not reusing
the standard ones which are available. In the long term, we would
like to mature standard DPDK nodes with flexibility of hooking them
to out-of-tree application nodes.
It would be ideal if the in-built nodes could be reused. When we started
working on grout, I tried multiple approaches where I could reuse these
nodes, but all failed. The nodes public API seems tailored for app/graph
but does not fit well with other control plane implementations.
One of the main issues I had is that the ethdev_rx and ethdev_tx nodes
are cloned per rxq / txq associated with a graph worker. The rte_node
API requires that every clone has a unique name. This in turn makes hot
plugging of DPDK ports very complex, if not impossible.
For example, with the in-built nodes, it is not possible to change the
number of ports or their number of RX queues without destroying the
whole graph and creating a new one from scratch.
Also, the current implementation of "ip{4,6}-rewrite" handles writing
ethernet header data. This would prevent it from using this node for an
IP-in-IP tunnel interface as we did in grout.
Do you think we could change the in-built nodes to enforce OSI layer
separation of concerns? It would make them much more flexible. It may
cause a slight drop of performance because you'd be splitting processing
in two different nodes. But I think flexibility is more important.
Otherwise, the in-built nodes can only be used for very specific
use-cases.
Finally, I would like to improve the rte_node API to allow defining and
enforcing per-packet metadata that every node expects as input. The
current in-built nodes rely on mbuf dynamic fields for this but this
means you only have 9x32 bits available. And using all of these may
break some drivers (ixgbe) that rely on dynfields to work. Have you
considered using mbuf private data for this?
2. Flexibility to enable/disable sub-graphs per interface based on the
runtime configuration updates. Protocol sub-graphs can be
selectively enabled for few (or all interfaces) at runtime
3. More than one sub-graphs/features can be enabled on an interface.
So a packet has to follow a sequential ordering node path on worker
cores. Packets may need to move from one sub-graph to another
sub-graph per interface
4. Last but not least, an optimized implementation which does not (or
minimally) stop worker cores for any control plane runtime updates.
Any performance regression should also be avoided
I am planning to create a draft presentation on feature arc which
I can share, when ready, to discuss. If needed, I can also plan to
present that in one of the DPDK community meetings. Their we can also
discuss if there are any alternatives of achieving above objectives
Looking forward to this.
Thanks!
