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 824FA42B8E; Wed, 24 May 2023 17:43:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4D70240156; Wed, 24 May 2023 17:43:12 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 1ECC4400EF; Wed, 24 May 2023 17:43:10 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 946BD5C012B; Wed, 24 May 2023 11:43:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 24 May 2023 11:43:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1684942987; x=1685029387; bh=aX5b8Iox2XfssI3xKPelT7kPVarwS9+w0O6 GoW1GfS4=; b=dXerus/f90IEgBo9y4G2r/8me0SfkL5nQ7nMPYfYBRpaaaCOzq6 n0+wzyjQpYEk6mfYr7mgZKRHf0yIj0sJaDLaaMl19utkdklWvUsZfYrLVRAeqMim n8fokTUQoeurHTbBY/hymAilke5nzZB7BwgBInOoVOn3Uj11Mdfoo4yNn3LFH02V CRsN6KDbSu8UzfYdIN1VabobihcImxJl0lKb7m8QrqtvVkIOAJFxD4FnbMfhkUys EW5j+2yGFaUXAQdLjXgSs6IBqkDTfPTlgNx7uiS2z3U8NmWD1uTM2afXSdjmuJL2 qTUk+MkukWksCvqY4hb93sGCbpe8G2RQRxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1684942987; x=1685029387; bh=aX5b8Iox2XfssI3xKPelT7kPVarwS9+w0O6 GoW1GfS4=; b=pX76mMGaSZ20wDR5SC03bRZtXaV5XAfpsgfeWvOIlzVGHDu9pmq u9OXa84N2xkNbynHv2z44Q8cjpUWW0Qwv+awu2KZWawq4vekdF+mxHwQdX9Qbhy2 7ib99Tzlo6QvMmhSipwyzAL/1j4nvqWNeBxBlylF9zhYS3eVvISy7rRXImvkm5SL fn5RVYO7hjrh0XKFjvE6Cms+hr+2V7+tO7TWCdzfWRb06LtRN8kaHfw6WVoxRkwA ED/Uotp2gN9hvZI5GdpKzO+mpSWRDe1pj7qkY7jG29NWSSxeLBE6X5noIefbLftO aHB63D42gEog/+S81BtUKLNWHD3G1j+BGCQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeejhedgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 May 2023 11:43:05 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: "Zhang, Qi Z" , techboard@dpdk.org, Ori Kam , "dev@dpdk.org" , "techboard@dpdk.org" , "Richardson, Bruce" , "Burakov, Anatoly" , "Wiles, Keith" , "Liang, Cunming" , "Wu, Jingjing" , "Zhang, Helin" , "Mcnamara, John" , "Xu, Rosen" , Kiran Kumar K , Satheesh Paul Subject: Re: seeking community input on adapting DPDK to P4Runtime backend Date: Wed, 24 May 2023 17:43:03 +0200 Message-ID: <1950495.jZfb76A358@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 24/05/2023 17:00, Jerin Jacob: > We did some study to use rte_flow on table driven _HW_ (HW has similar > capability to p4 table) > Following are the observations that need improvement in rte_flow. > > > 1) HW engines require more resources for ACL (considering the > algorithmic HW implementation and table size is in handful of > millions), > whereas EM, LPM needs less HW resources, In p4, we have means to > express this, in rte_flow, in general assumption it is ACL. > We may need to express the mode in rte_flow_template_table_create() or > so. Otherwise, > more than one rte_flow_pattern_template* templates > pattern_template_index of rte_flow_async_create() creates > conflicting modes. In p4, mode is associated with a table, and it has > fixed KEY and VALUE. This area in the rte_flow requires > improvement if we need to use with p4 type HW. > > 2) rte_flow is purely in working "inline" mode, If CPU core needs to > do lookup on the table created. We require some APIs > to look-aside mode support. > > 3) Handling of raw action data > > a) In p4, Action value is opaque, so maybe we need to have action RAW > where value can be running > number from 0 to VALUE - 1. > > b) Expressing the handling compute operation after lookup. > rte_flow_actions are fixed in nature, which > would suffice for a lot of use case. Expressing the following case may > be difficult with rte_flow now. > > For example: > value_from_lookup = lookup(packet, key); > if ((packet.filed[x] && value_value_from_lookup) == value_x) { > packet.field[x] += value_y; > packet.field[x] ^= value_z; > } > > I think, such general programming paradigm kind of action may need > ePBF kind program to express. > Where we can add new RTE_FLOW_ACTION_LOAD_EPF_PROGRAM to run through a > simple program after table lookup. > > Either, we can update the rte_flow to address the cases reported in the thread > or enhance the current rte_table library(which already has a function > pointer based backend) and > create an object using the rte_table API and connect the table object > with rte_flow API. > > I think, we should try to enhance rte_flow for more native table > support if possible. I agree to enhance rte_flow in general. I suspect that most of features above are already possible using some unknown properties of rte_flow. For instance, modifying a packet is possible with RTE_FLOW_ACTION_TYPE_MODIFY_FIELD.