DPDK patches and discussions
 help / color / mirror / Atom feed
From: Christophe Fontaine <cfontain@redhat.com>
To: Robin Jarry <rjarry@redhat.com>
Cc: Nitin Saxena <nsaxena16@gmail.com>,
	David Marchand <david.marchand@redhat.com>,
	Nitin Saxena <nsaxena@marvell.com>,
	Jerin Jacob <jerinj@marvell.com>,
	Kiran Kumar Kokkilagadda <kirankumark@marvell.com>,
	Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
	Zhirun Yan <yanzhirun_163@163.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [EXTERNAL] [RFC PATCH 0/3] add feature arc in rte_graph
Date: Thu, 17 Oct 2024 10:32:04 +0200	[thread overview]
Message-ID: <509C9EDF-701F-4F7F-9E08-462FD378FF1B@redhat.com> (raw)
In-Reply-To: <D4XX15NOJ8I8.H77MX29GJMEB@redhat.com>

Hi all,

What about the following steps:
- update the nodes so they work on the current layer (example: for all L3 nodes, the current mbuf data offset *must* be pointing to the IP header)
- define a public data structure that would be shared across nodes through priv data, and not dynfields ? This structure would be the "internal api" (so, that has to be tracked across dpdk releases) between nodes.
We’d need common data shared for all the nodes as well as specific data between 2 nodes.
As we get to this point, this (hopefully) will help with the node reusability.

- Update the feature arcs to leverage this well known structure, and refine the api
- Define which part of the stack needs to be defined as a feature arc, with the benefit of the generic API to enable/disable that feature, and which part needs to be dynamically pluggable.
For instance, for a router, it may not make sense to define IPv4 support as a feature arc.
So, we’d statically connect eth_input to ip_input.
Yet, lldp support is a good candidate for a feature arc: we need to configure it per interface, and this is independent of the main graph.

WDYT?
Christophe

> On 17 Oct 2024, at 09:50, Robin Jarry <rjarry@redhat.com> wrote:
> 
> 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!
> 


  reply	other threads:[~2024-10-17  8:32 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-07  7:31 Nitin Saxena
2024-09-07  7:31 ` [RFC PATCH 1/3] graph: add feature arc support Nitin Saxena
2024-09-11  4:41   ` Kiran Kumar Kokkilagadda
2024-10-10  4:42     ` Nitin Saxena
2024-09-07  7:31 ` [RFC PATCH 2/3] graph: add feature arc option in graph create Nitin Saxena
2024-09-07  7:31 ` [RFC PATCH 3/3] graph: add IPv4 output feature arc Nitin Saxena
2024-10-08  8:04 ` [RFC PATCH 0/3] add feature arc in rte_graph David Marchand
2024-10-08 14:26   ` [EXTERNAL] " Nitin Saxena
2024-10-14 11:11   ` Nitin Saxena
2024-10-16  9:24     ` David Marchand
2024-10-16  9:38       ` Robin Jarry
2024-10-16 13:50         ` Nitin Saxena
2024-10-17  7:03           ` Nitin Saxena
2024-10-17  7:50             ` Robin Jarry
2024-10-17  8:32               ` Christophe Fontaine [this message]
2024-10-17 10:56                 ` [EXTERNAL] " Nitin Saxena
2024-10-17  8:48               ` [EXTERNAL] " Nitin Saxena
2024-10-08 13:30 ` [RFC PATCH v2 0/5] " Nitin Saxena
2024-10-08 13:30   ` [RFC PATCH v2 1/5] graph: add feature arc support Nitin Saxena
2024-10-08 13:30   ` [RFC PATCH v2 2/5] graph: add feature arc option in graph create Nitin Saxena
2024-10-08 13:30   ` [RFC PATCH v2 3/5] graph: add IPv4 output feature arc Nitin Saxena
2024-10-08 13:30   ` [RFC PATCH v2 4/5] test/graph_feature_arc: add functional tests Nitin Saxena
2024-10-08 13:30   ` [RFC PATCH v2 5/5] docs: add programming guide for feature arc Nitin Saxena
2024-10-09 13:29   ` [PATCH v3 0/5] add feature arc in rte_graph Nitin Saxena
2024-10-09 13:29     ` [PATCH v3 1/5] graph: add feature arc support Nitin Saxena
2024-10-09 13:29     ` [PATCH v3 2/5] graph: add feature arc option in graph create Nitin Saxena
2024-10-09 13:30     ` [PATCH v3 3/5] graph: add IPv4 output feature arc Nitin Saxena
2024-10-09 13:30     ` [PATCH v3 4/5] test/graph_feature_arc: add functional tests Nitin Saxena
2024-10-09 13:30     ` [PATCH v3 5/5] docs: add programming guide for feature arc Nitin Saxena
2024-10-09 14:21     ` [PATCH v3 0/5] add feature arc in rte_graph Christophe Fontaine
2024-10-10  4:13       ` [EXTERNAL] " Nitin Saxena
2024-10-09 17:37     ` Stephen Hemminger
2024-10-10  4:24       ` [EXTERNAL] " Nitin Saxena
2024-10-10 13:31     ` [PATCH v4 " Nitin Saxena
2024-10-10 13:31       ` [PATCH v4 1/5] graph: add feature arc support Nitin Saxena
2024-10-10 13:31       ` [PATCH v4 2/5] graph: add feature arc option in graph create Nitin Saxena
2024-10-10 13:31       ` [PATCH v4 3/5] graph: add IPv4 output feature arc Nitin Saxena
2024-10-10 13:31       ` [PATCH v4 4/5] test/graph_feature_arc: add functional tests Nitin Saxena
2024-10-10 13:31       ` [PATCH v4 5/5] docs: add programming guide for feature arc Nitin Saxena
2024-10-14 14:33       ` [PATCH v5 0/5] add feature arc in rte_graph Nitin Saxena
2024-10-14 14:33         ` [PATCH v5 1/5] graph: add feature arc support Nitin Saxena
2024-10-14 14:33         ` [PATCH v5 2/5] graph: add feature arc option in graph create Nitin Saxena
2024-10-14 14:33         ` [PATCH v5 3/5] graph: add IPv4 output feature arc Nitin Saxena
2024-10-14 14:33         ` [PATCH v5 4/5] test/graph_feature_arc: add functional tests Nitin Saxena
2024-10-14 19:54           ` Stephen Hemminger
2024-10-14 14:33         ` [PATCH v5 5/5] docs: add programming guide for feature arc Nitin Saxena

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=509C9EDF-701F-4F7F-9E08-462FD378FF1B@redhat.com \
    --to=cfontain@redhat.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=jerinj@marvell.com \
    --cc=kirankumark@marvell.com \
    --cc=ndabilpuram@marvell.com \
    --cc=nsaxena16@gmail.com \
    --cc=nsaxena@marvell.com \
    --cc=rjarry@redhat.com \
    --cc=yanzhirun_163@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).