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 42B3245B91; Mon, 21 Oct 2024 14:53:24 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 305B3402DA; Mon, 21 Oct 2024 14:53:24 +0200 (CEST) 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 D816140263 for ; Mon, 21 Oct 2024 14:53:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729515201; 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=6Po0Q2K/NGFMxcwvjvLCb4nIAw0V0h2wQbf5zYIEzAs=; b=O+9YFzJJtFWxxl0heSBtr2MOjy2R75o37iaNNJXC0/Hu3QS5fO9prjTwfSP/Znx9OVkqdy vD66jKlo2tUboh57BiWKUcEOeHb7iZM3JjH8nInAFrzWcVVZWbV197efv5c8LdYALmG2Dp IZQw+z7Tzlc16SIhFgeRj0/lvzR2Y4c= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-68-F_7J8y3lPOOgF2eKGlVCOQ-1; Mon, 21 Oct 2024 08:53:20 -0400 X-MC-Unique: F_7J8y3lPOOgF2eKGlVCOQ-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-37d45de8bbfso3128528f8f.3 for ; Mon, 21 Oct 2024 05:53:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729515199; x=1730119999; h=user-agent:to:from:cc:subject:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=6Po0Q2K/NGFMxcwvjvLCb4nIAw0V0h2wQbf5zYIEzAs=; b=JGeZfpPU1ooCxsHFWahZ/RjD3SoUSqEsUSkF0iMNglKzFZrYzb43OrrN9a5OGCeRV9 prs44wIoxR1Jyr1hCEFrIXFmqHC6aIpEQPKueTBD1wB3B9lhwQYIamRsG9sbzAHym3KD LdS71gXHBs6Vtjtpz5E9YGgZ/uGUoonBkM1lr/EXApRsUk7kjMWCNlgFxQ7qx2rUQnXJ OqsrzOIy+I6VtI3EvY2FoQLSaY3RiV6FzEmT4Vjk9zD21LaTKPKcuI5I9mXa6Yf+75wo lqvDAoulyIUd5xhG6pNkHdhJVAc56mcQKio+/JKWjWofPA3Diaa7qop6GrdSlLar14f2 bR+A== X-Gm-Message-State: AOJu0YzoDct7k95CnFevmNSCWB7ztWXs7BNxVhIUVtQYqmkhOLVeKeUC q0JAichVC9oQm53ObYiryNap8yskpgHphaRy+KIe5L22fh3hdBko/vzeI5Rmw83ko2jrDQFG4i9 pMxycjz9O1ihOq6AAijgLNOOAoa0b468dgJ1ZPmBf1q3qiQWt9TwgMAf9fh+6Y4RB8wure8ae+Y gl8klPeKExAuzRygNxvC22Bw== X-Received: by 2002:adf:f645:0:b0:37d:4c40:699 with SMTP id ffacd0b85a97d-37ea21c3e39mr10003386f8f.5.1729515198901; Mon, 21 Oct 2024 05:53:18 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGhj2Bu4r2aqLjvCdvx33Sp13yT/Wn816k0ZMKEA+jvT4xnEllF2mNdnx0BEgwKSu56fdPFJQ== X-Received: by 2002:adf:f645:0:b0:37d:4c40:699 with SMTP id ffacd0b85a97d-37ea21c3e39mr10003364f8f.5.1729515198479; Mon, 21 Oct 2024 05:53:18 -0700 (PDT) Received: from localhost (2a01cb00025433006239e1f47a0b2371.ipv6.abo.wanadoo.fr. [2a01:cb00:254:3300:6239:e1f4:7a0b:2371]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37ee0a58cd2sm4277426f8f.55.2024.10.21.05.53.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Oct 2024 05:53:18 -0700 (PDT) Mime-Version: 1.0 Date: Mon, 21 Oct 2024 14:53:17 +0200 Message-Id: Subject: graph: make the in-built nodes better reusable Cc: "Jerin Jacob" , "Nitin Saxena" , "David Marchand" , "Christophe Fontaine" From: "Robin Jarry" To: , User-Agent: aerc/0.18.2-82-g9e557d0f289f 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 all, I am starting this discussion to see what can be done in order to make=20 the in-built nodes (i.e. https://git.dpdk.org/dpdk/tree/lib/node) easier=20 to reuse in external applications. So far here are the limitations I have found when working on grout. Some=20 of these limitations are trivial, some others are more tricky. I hope we=20 can get clean solutions. ethdev_rx and ethdev_tx require cloning --------------------------------------- These nodes have been written to receive from or transmit to a single=20 queue. When changing the number of ports and/or rx/tx queues. The graph=20 needs to be recreated. * Node names must all be unique (hence, node clones need to have=20 different names than their original). =3D> There is a routine that automatically adds a "unique" suffix to the= =20 cloned ethdev_rx and ethdev_tx names. The "ethdev_rx--"=20 and "ethdev_rx-" name patterns are used. =3D> it is not possible to prepare the new nodes in advance without=20 destroying the active graph. For example, if one port+queue isn't=20 changed, the "ethdev_rx--" name will already exist and be=20 active in the graph. Reusing the same name could lead to data races. * Node context data cannot be passed during rte_graph_create() or=20 rte_graph_clone(). Instead, each node init() callback must determine its own context data=20 based on the graph and node pointers it has. In most cases, it is=20 trivial, but not for nodes that have multiple copies per graph. * Once created/cloned, nodes cannot be destroyed. =3D> Removing ports and/or reducing the number queues, results in node=20 clones remaining. It isn't the end of the world but it would be nice=20 to allow destroying them for clarity. * Graph statistics are per-node. =3D> When cloning nodes, we end up with obscure node names such as=20 "ethdev_rx-4-7" in graph statistics. It would be clearer if the clones=20 would be collapsed in the statistics. Having clones is an=20 implementation detail which shouldn't reflect in the results. Same with the DOT graph dump, it makes the graph images bloated and=20 also gives a different image per worker. It would be clearer if the=20 original node name was used only. ip* nodes assume the mbuf data offset is at 0 --------------------------------------------- L3 and L4 nodes assume that the mbuf they process have their data=20 offsets pointing to an ethernet header. This prevents implementing IP tunnels or control to data plane=20 communication where the data pointer may need to be at the end of the=20 L3 header, for example. If we change that to adjust the data pointer to the correct OSI layer,=20 it would also mandate that each individual node only deals with a single=20 OSI layer. This means that the current ip*_rewrite nodes would need to be split in=20 two: ip*_output and eth_output. This may have big implications on the=20 optimizations that were made in these nodes. No explicit API to pass application specific data around -------------------------------------------------------- This one is more a documentation issue. It would help if there was=20 a clear description of how the in-built nodes work together and what=20 kind of mbuf private data they require in order to function properly. Next nodes are hard coded ------------------------- All next-nodes are set in the in-built nodes. This prevents from reusing=20 only a subset of them. No support for logical interfaces --------------------------------- All interfaces are supposed to be DPDK ports (e.g. IP next hops contain=20 destination Ethernet addresses and DPDK port IDs). This prevents support=20 of logical interfaces such as IP tunnels. No support for multiple VRF --------------------------- There is a single lpm/lpm6 instance for all ports. This is sort of=20 linked to the previous limitation about no having support for logical=20 interfaces. Ideally, the lpm/lpm6 instance should be determined from the=20 VRF identifier of the input interface (nb: NOT the same thing as=20 receiving DPDK port). Cheers! --=20 Robin