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 7474C43D02; Mon, 25 Mar 2024 15:17:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 07D1640271; Mon, 25 Mar 2024 15:17:32 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 683AA4021D for ; Mon, 25 Mar 2024 15:17:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711376250; 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; bh=WqK/eGm/jPQ8Y+8lDSRJqPUpEJl0udfoA1UwkzlZ6+w=; b=f8Cavj3SbkikcbIPd8Ayg265NezJGGUWP7EzHiJyD9QftMcqziH3154d5rQxrtBahzi/DY CVRotfPnyyCV2tGolIgdtrpV/EHupF4CHhcmC8MpRa52TS1pFWFkM9WYaNtreZGq6B5igz sKE2FMn9V1vRtkd0clDTEAkgGunrrR4= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-126-GAG3CSx0MaCeufiM23dG1g-1; Mon, 25 Mar 2024 10:17:27 -0400 X-MC-Unique: GAG3CSx0MaCeufiM23dG1g-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-513d4bcca5eso3360472e87.2 for ; Mon, 25 Mar 2024 07:17:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711376245; x=1711981045; h=mime-version:to:from:cc:subject:message-id:date :content-transfer-encoding:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=WqK/eGm/jPQ8Y+8lDSRJqPUpEJl0udfoA1UwkzlZ6+w=; b=oDPUaIbD+tJzG+boz5osdES/DP3bD2a9S5044ABvMrhq78UIdkmadEPbqlDNh2e3ha xvTmYYY6mu6ALXG0LpbFW9Zp1dVNLWdV0IetM84i+bcCzpaWG0fYF7S4p0Qc3HSVC+AV M2FphGnTbiEJ2D06Af4wfuylImuQ9Ms4+ekQyFTZ4Gd/R/QEjcSv9Cpt+yNTLAWLnerq fR6QoJD/WuSOX1Upt17g5HL95a+ycZBvLoQ1r85w0rDRxyUz+D9robezqvNZ5pbqYZQ/ 1d2T0M076ccYLtsOhOqTl+wvnqyKbirB3EGMuGZjJJ1Spff/YEUW3rgVY+1+sp3U8qoE 9VgA== X-Gm-Message-State: AOJu0YwAUTuA3JDemd9k09sdgh0U+6x3hjQaxHtp0Togv1SKAj+Z5VHt UpT65a0BWGQPQgI6OV/n2HNp3VMubAOZKCwBMDAbBG0peijUS5MKx3i+qL47QAoonUJMXkbAqF3 uj1m69j1olzwBnEHgXWJP5D2Ju1gyWk5HnfMnLzK/G/cEkOnXCsLxnSuqJEpZEO6QmX0TV3uMrL erQKr/SK3KGUuKMtlOO3XmNA== X-Received: by 2002:a19:ca07:0:b0:513:a833:cda2 with SMTP id a7-20020a19ca07000000b00513a833cda2mr4826534lfg.53.1711376245595; Mon, 25 Mar 2024 07:17:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFQ/eqAGpVTkkr9NZACo/qHtcqpz0E2HY2j7orqoqEO0wvKXzxaulY6fIveQZOGtDXuhqQT1A== X-Received: by 2002:a19:ca07:0:b0:513:a833:cda2 with SMTP id a7-20020a19ca07000000b00513a833cda2mr4826505lfg.53.1711376245103; Mon, 25 Mar 2024 07:17:25 -0700 (PDT) Received: from localhost (2a01cb000f8b9700598da2e1679e8383.ipv6.abo.wanadoo.fr. [2a01:cb00:f8b:9700:598d:a2e1:679e:8383]) by smtp.gmail.com with ESMTPSA id g27-20020ac24d9b000000b00513c86486b5sm1088537lfe.6.2024.03.25.07.17.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Mar 2024 07:17:24 -0700 (PDT) Date: Mon, 25 Mar 2024 15:17:23 +0100 Message-Id: Subject: [RFC] graph/node: feedback and future improvements Cc: "Kiran Kumar K" , "Nithin Dabilpuram" , "Pavan Nikhilesh" , "Hongbo Zheng" , "Zhirun Yan" From: "Robin Jarry" To: , "Jerin Jacob" MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; format=Flowed 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 Jerin, all, I apologize in advance for the long email :) I am working on a project [1] that uses rte_graph extensively. In the=20 course of action, I have stumbled upon a few issues. I managed to work=20 around them for now, but I'd like to get more insights about long term=20 solutions. Per Rx/Tx queue nodes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the in-built nodes and in the examples, there is one ethdev_rx and=20 ethdev_tx node per rx/tx queue [2]. Is there a technical reason for this design? Does it make sense to have=20 only one of each ethdev_rx and ethdev_tx nodes per graph? For simplicity=20 and to make dynamic rxq changes possible, I chose to have a single rx=20 & tx node per graph. Do you think we could change the in-built nodes to=20 support both modes ? Having multiple instances of the same node in a graph complicates=20 instantiation as it requires cloning the nodes with unique names. Also,=20 it makes dynamic configuration of ports even more complicated without=20 shutting down everything first since some nodes will be part of an=20 active graph and there may be conflicts. Speaking of graph reloading, I found that the in-built ethdev_tx TX=20 queue id is initialized to graph_id [3]. This seems odd. If there are=20 multiple rounds of graph create/destroy, the id will become invalid. Dynamic graph and nodes construction/destruction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I need to deal with reconfiguration of the graphs at runtime. This can=20 happen on multiple occasions: port addition/suppression, number of rxq=20 change, rxq size change, etc. I could not manage to reuse the in-built nodes because of the issues=20 raised in the previous point. Could we change the in-built nodes to better support dynamic reloading?=20 Maybe this only applies to nodes that may appear multiple times in the=20 same graph (rx/tx). Node context data =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There is no way to prepare node data context when calling=20 rte_graph_create(). The current implementation uses global variables [4]=20 but this makes it very "static". It would be nice to pass prepared context data for every node on graph=20 creation, either via a config parameter (better) or via another=20 mechanism. I currently do this via a hash map but it requires a global=20 hash as well which may not be the best solution. I tried patching the graph library code myself but after struggling,=20 I thought it would be best to discuss things first. Pluggable nodes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Currently, the declaration of next nodes is static. In order to support=20 plugins (e.g. via dlopen() or similar), could we introduce a way to=20 dynamically insert a node in the graph? I have done this using a post-init callback system but we could think of=20 a different way. Also, could we allow overriding nodes with RTE_NODE_REGISTER()? So users=20 can replace the default implementation with their own if they need to. Move data pointer of packets? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D This final point is more a global design question. In traditional=20 networking stacks, each layer of the stack receives pbuffers that are=20 "adjusted" to their respective network header in the packet (i.e. the IP=20 lookup function will receive a buffer that points to the beginning of=20 the IP header, regardless of what was the transport protocol, plain=20 ethernet, Ethernet + VLAN, IP in IP, etc.). Would it make sense to have a similar mechanism when designing an=20 application with rte_graph? Thanks in advance for your replies. Cheers! --=20 Robin [1] https://github.com/rjarry/brouter [2] https://github.com/DPDK/dpdk/blob/v23.11/lib/node/ethdev_rx.c#L28 [3] https://github.com/DPDK/dpdk/blob/v23.11/lib/node/ethdev_tx.c#L56 [4] https://github.com/DPDK/dpdk/blob/v23.11/lib/node/ethdev_ctrl.c