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 D347A45B5A; Thu, 17 Oct 2024 09:50:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 89FDC402E2; Thu, 17 Oct 2024 09:50:55 +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 A760040261 for ; Thu, 17 Oct 2024 09:50:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729151453; 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=lW75US5C2F5ZqWWDBtJc2JsVEzcsRKZJ/EJuc7j3U/g=; b=dhz2kLrfhKpCFXEdj31/hYOZBn5yCHOTH46ZO9ehV62YVJegsHpckVmpi/ow+nFnUk88i3 gpAnND9gCUdV4pfpdy+MR5FON+wGqjUHreyYHoFFMrWLd8dVoyzOjlHp/EmbgGW/VOmCer LDsSKq7LzACeYs7/U9voM+lNSygOe6Y= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-658-d6Ai88ZwNGe3oYjlgClIPA-1; Thu, 17 Oct 2024 03:50:52 -0400 X-MC-Unique: d6Ai88ZwNGe3oYjlgClIPA-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-43157cff1d1so4902415e9.2 for ; Thu, 17 Oct 2024 00:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729151451; x=1729756251; h=in-reply-to:references:user-agent:cc:subject:to:from:message-id :date:content-transfer-encoding:mime-version:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=lW75US5C2F5ZqWWDBtJc2JsVEzcsRKZJ/EJuc7j3U/g=; b=M629fh4FPWOU52hve55Rm/AGMWjYys7Mynu8qo+Ijhhef8yNmgULOgz+dZveUHnArx e2cnwZUFgaQcR5ApeKBqoCxl08v4lEyTIk1MzLKl7Ym56ygEEAehNFZhL85vV6F3qJUz NYYI/ejYWfqen3PaVQdwyqa1zPKS1Nsf0bZJ3G65MlgPsZW+uDIy39BnX4p4dlRzT7UQ DDinWnDKP8JLzpU6CDOGwIE/EnH8KzBKQcZOf2fHUmcvQTgFSrXp4jiY3wKbYqsEodOM mfGDbPLz9vCWxZPcLUYAiXAdsRSDcPXXT5vTHVbkdBMj+LACDnl2GH/veu7coSxOMQDD yuvA== X-Forwarded-Encrypted: i=1; AJvYcCUT+nWIH8QJ6795fmhptgO8boHXu+VzwzFpSP3cW3X+ZcQHQvP07SbwOw3Cjj0ezGW+oBQ=@dpdk.org X-Gm-Message-State: AOJu0YyVAcXkjHPs540V58YUedwWpi4NF5CdfSse8VgxA2kVgD0vQzi8 H8K2e7kupoPWDyQgIPj6EDjwE/JCV7xUyBiNGXKTDt1NUNKRap/vDNcq1TK9zRcB6mh3pUHnt9w SxAnLtfj6LpPW+pD28fDTET8Ht3bbv1G8qDfBMrUP X-Received: by 2002:a05:600c:3585:b0:431:588a:44a2 with SMTP id 5b1f17b1804b1-431588a4699mr15178345e9.12.1729151450898; Thu, 17 Oct 2024 00:50:50 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHsNCgsdfjiLsNr74jGqNWlSIQBvkLwbB8E27rNWjQ+mI0OTrUJYlJsEC3p+EUpSn6srDUFCA== X-Received: by 2002:a05:600c:3585:b0:431:588a:44a2 with SMTP id 5b1f17b1804b1-431588a4699mr15178215e9.12.1729151450483; Thu, 17 Oct 2024 00:50:50 -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 5b1f17b1804b1-43158c617cesm17253135e9.41.2024.10.17.00.50.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Oct 2024 00:50:50 -0700 (PDT) Mime-Version: 1.0 Date: Thu, 17 Oct 2024 09:50:49 +0200 Message-Id: From: "Robin Jarry" To: "Nitin Saxena" Subject: Re: [EXTERNAL] Re: [RFC PATCH 0/3] add feature arc in rte_graph Cc: "David Marchand" , "Nitin Saxena" , "Jerin Jacob" , "Kiran Kumar Kokkilagadda" , "Nithin Kumar Dabilpuram" , "Zhirun Yan" , "dev@dpdk.org" , "Christophe Fontaine" User-Agent: aerc/0.18.2-81-g43ce621f36dd References: <20240907073115.1531070-1-nsaxena@marvell.com> In-Reply-To: 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 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=20 > a new concept. Our objectives are following with feature arc changes > > 1. Allow reusability of standard DPDK nodes (defined in lib/nodes/*)=20 > with out-of-tree applications (like grout). Currently out-of-tree=20 > graph applications are duplicating standard nodes but not reusing=20 > the standard ones which are available. In the long term, we would=20 > like to mature standard DPDK nodes with flexibility of hooking them=20 > to out-of-tree application nodes. It would be ideal if the in-built nodes could be reused. When we started=20 working on grout, I tried multiple approaches where I could reuse these=20 nodes, but all failed. The nodes public API seems tailored for app/graph=20 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=20 are cloned per rxq / txq associated with a graph worker. The rte_node=20 API requires that every clone has a unique name. This in turn makes hot=20 plugging of DPDK ports very complex, if not impossible. For example, with the in-built nodes, it is not possible to change the=20 number of ports or their number of RX queues without destroying the=20 whole graph and creating a new one from scratch. Also, the current implementation of "ip{4,6}-rewrite" handles writing=20 ethernet header data. This would prevent it from using this node for an=20 IP-in-IP tunnel interface as we did in grout. Do you think we could change the in-built nodes to enforce OSI layer=20 separation of concerns? It would make them much more flexible. It may=20 cause a slight drop of performance because you'd be splitting processing=20 in two different nodes. But I think flexibility is more important.=20 Otherwise, the in-built nodes can only be used for very specific=20 use-cases. Finally, I would like to improve the rte_node API to allow defining and=20 enforcing per-packet metadata that every node expects as input. The=20 current in-built nodes rely on mbuf dynamic fields for this but this=20 means you only have 9x32 bits available. And using all of these may=20 break some drivers (ixgbe) that rely on dynfields to work. Have you=20 considered using mbuf private data for this? > > 2. Flexibility to enable/disable sub-graphs per interface based on the=20 > runtime configuration updates. Protocol sub-graphs can be=20 > selectively enabled for few (or all interfaces) at runtime > > 3. More than one sub-graphs/features can be enabled on an interface.=20 > So a packet has to follow a sequential ordering node path on worker=20 > cores. Packets may need to move from one sub-graph to another=20 > sub-graph per interface > > 4. Last but not least, an optimized implementation which does not (or=20 > minimally) stop worker cores for any control plane runtime updates.=20 > Any performance regression should also be avoided > > I am planning to create a draft presentation on feature arc which=20 > I can share, when ready, to discuss. If needed, I can also plan to=20 > present that in one of the DPDK community meetings. Their we can also=20 > discuss if there are any alternatives of achieving above objectives Looking forward to this. Thanks!