From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D2FD445B5C; Thu, 17 Oct 2024 10:32:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 981D240279; Thu, 17 Oct 2024 10:32:21 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id CFE5940273 for ; Thu, 17 Oct 2024 10:32:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729153939; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fBGZpVEa7OduOYl5/n8htxpeDfvXz1RHxZr5RPpzIe8=; b=NDD4QLnwreueotVV5b5nfoHGImRFD7GL29f+hEBp42Zlj90POxoNOpbeIAHQyoXFul+gVE bINWNIyI/CyDC0RrVtG8iTO8YuG7EAGUkV74vLV3cTZ5DBnJxav0o3E5Nh+kfSb4197wgO EmzzWB7EVFyM5Zj32LAzAzEZTMS0SIk= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-355--BUL5bxNME-HSEqUNWMjog-1; Thu, 17 Oct 2024 04:32:18 -0400 X-MC-Unique: -BUL5bxNME-HSEqUNWMjog-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-37d4922d8c7so270998f8f.1 for ; Thu, 17 Oct 2024 01:32:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729153936; x=1729758736; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0QlrEEQVuURQYj7xhHg56bpwPbR+T/Updv5r1fxf/Og=; b=oFRlgZya/WYu3dSJRdqxq79iDibmw1jP4X8A2ITdxWFtQ10Tqg670JP5Gpdr1luKUA Ud/a8mwp4W9kObkQDlANZR607YBMhp+N6OyUObXVmdx9J/v4QAe3PbkQdVun0/pKON9H qBBJpcwgOD1tfJ7nDsOpIDCgLxXLrR04kdVebn/rwyqvIgbVFjFxyZtAFNoLtU1m3JgC Wp8qjxyolb9l0ejUll9rcKIJNix4K6zDhZnB+dSNXcG2QQL0kIhVBJCXkFih5oX63rr7 B7bDKnbbGP7MjZKogGf4C2Gfja93ayPCqtfAvNJGXC1sOcgQP73yPPdcnvMrFEGWLy3L Z03A== X-Forwarded-Encrypted: i=1; AJvYcCV7yXKbrs6G+9F0MMF5vcwIaWGxAvkoD0bl0jxYf1JUkS1QZRdnv4xLkwuyH48rDKGd6J4=@dpdk.org X-Gm-Message-State: AOJu0Yxg/IHla8uW4CKNz46zNFd7LHaAoGGoSA9wJNlDu3ZhlIJIhNpO UJAwJqyLFtTYOGdpQ4B1AopkRxMA1HLkSO2FSZQuOQkEmrrgfdg2J+T8B3vV62Q16e2Vjh+QkYr aUJGcvLKsF7PJINAGS9tQtIKE9/G7EtveeRM/l8KL4kGmzqOl X-Received: by 2002:a5d:69c6:0:b0:37d:3985:8871 with SMTP id ffacd0b85a97d-37d5ffc02a8mr12469387f8f.39.1729153936304; Thu, 17 Oct 2024 01:32:16 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGAhoOd6j1vhUTQwxkYBKOetMsqHcTsjbokJTjKvQEvqQEIzm2eJTbgLCYa3pjjzCSsbhQnCQ== X-Received: by 2002:a5d:69c6:0:b0:37d:3985:8871 with SMTP id ffacd0b85a97d-37d5ffc02a8mr12469355f8f.39.1729153935810; Thu, 17 Oct 2024 01:32:15 -0700 (PDT) Received: from smtpclient.apple ([2a01:cb19:141e:f200:81c8:9c9d:5db8:f97b]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d7fa7a1e0sm6643871f8f.9.2024.10.17.01.32.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Oct 2024 01:32:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\)) Subject: Re: [EXTERNAL] [RFC PATCH 0/3] add feature arc in rte_graph From: Christophe Fontaine In-Reply-To: Date: Thu, 17 Oct 2024 10:32:04 +0200 Cc: Nitin Saxena , David Marchand , Nitin Saxena , Jerin Jacob , Kiran Kumar Kokkilagadda , Nithin Kumar Dabilpuram , Zhirun Yan , "dev@dpdk.org" Message-Id: <509C9EDF-701F-4F7F-9E08-462FD378FF1B@redhat.com> References: <20240907073115.1531070-1-nsaxena@marvell.com> To: Robin Jarry X-Mailer: Apple Mail (2.3818.100.11.1.3) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi all, What about the following steps: - update the nodes so they work on the current layer (example: for all L3 n= odes, 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=E2=80=99d 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 reusabili= ty. - 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 p= art 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=E2=80=99d statically connect eth_input to ip_input. Yet, lldp support is a good candidate for a feature arc: we need to configu= re it per interface, and this is independent of the main graph. WDYT? Christophe > On 17 Oct 2024, at 09:50, Robin Jarry wrote: >=20 > Hi Nitin, all, >=20 > Nitin Saxena, Oct 17, 2024 at 09:03: >> Hi Robin/David and all, >>=20 >> We realized the feature arc patch series is difficult to understand as a= new concept. Our objectives are following with feature arc changes >>=20 >> 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 sta= ndard DPDK nodes with flexibility of hooking them to out-of-tree applica= tion nodes. >=20 > 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 nod= es, but all failed. The nodes public API seems tailored for app/graph but d= oes not fit well with other control plane implementations. >=20 > One of the main issues I had is that the ethdev_rx and ethdev_tx nodes ar= e cloned per rxq / txq associated with a graph worker. The rte_node API req= uires that every clone has a unique name. This in turn makes hot plugging o= f DPDK ports very complex, if not impossible. >=20 > For example, with the in-built nodes, it is not possible to change the nu= mber of ports or their number of RX queues without destroying the whole gra= ph and creating a new one from scratch. >=20 > Also, the current implementation of "ip{4,6}-rewrite" handles writing eth= ernet header data. This would prevent it from using this node for an IP-in-= IP tunnel interface as we did in grout. >=20 > Do you think we could change the in-built nodes to enforce OSI layer sepa= ration of concerns? It would make them much more flexible. It may cause a s= light drop of performance because you'd be splitting processing in two diff= erent nodes. But I think flexibility is more important. Otherwise, the in-b= uilt nodes can only be used for very specific use-cases. >=20 > Finally, I would like to improve the rte_node API to allow defining and e= nforcing 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 (i= xgbe) that rely on dynfields to work. Have you considered using mbuf privat= e data for this? >=20 >>=20 >> 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 >>=20 >> 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 core= s. Packets may need to move from one sub-graph to another sub-graph per = interface >>=20 >> 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 >>=20 >> 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 i= n one of the DPDK community meetings. Their we can also discuss if there ar= e any alternatives of achieving above objectives >=20 > Looking forward to this. >=20 > Thanks! >=20