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 6CFC84240B; Wed, 18 Jan 2023 09:50:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2530840DFD; Wed, 18 Jan 2023 09:50:54 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 7E33E4003F for ; Wed, 18 Jan 2023 09:50:52 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id AB0173200094; Wed, 18 Jan 2023 03:50:49 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 18 Jan 2023 03:50:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding: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=fm3; t=1674031849; x= 1674118249; bh=i+Y/YSWeiS6foc7xAgLYEZi1P/pZfE4xjRv9jy7o5TE=; b=k bPz/L7h4hkMIC7saLyYUzKCkIYwT0QsSfwn8elLeRQbkiT/RVevjPlxUu+aIDtFO LnQIK8sRHfIY4oUuCZiAecRJLC4jugWKRJ5kkPIQp5V6FsxXz+XUYKevjmDCDaqC VT8kx+f2QBYEMxHLO1VusCYHFRRZPmYa7AC6DW1P8mB8mF4GvBAmyW5U0sHgAKcv OI+lbvPbLnqfGpZTkaWLxfdHKhNwremREzGtSd8HhkOe2uDzF3KeJWSROkYXn4UD 2xQ7XAMuGR4EfDA+A4/s1LD82qwcGmutU3dXzCI/nbnSsrGLCeVOWxsXZQxE3gFk c/9Nwe5A55jHL+SKp/GvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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=fm3; t=1674031849; x= 1674118249; bh=i+Y/YSWeiS6foc7xAgLYEZi1P/pZfE4xjRv9jy7o5TE=; b=P QNAxxc+VS9Ah9jbe9dl088xfhKoys1amIhFkyol71By5UHyTTF6IPe0LIzukJwxJ vCEumIGH3y4EmFREseLJT9nto803oiZAQRCB89NCPZhqtoaPYVohA0mdEbiaFA3I fLCTPpobn/PpbYMzbhCSSSxs9CMx60bhvzCR5EVE5QTcAXmQaHokooRPR+nLH9qV /XA/z8OCbrLN4CFCfgx8hRKUc/BKTRaHnb8dGjZYod793LRexp7eGOI7f2X4ecPb byBVSBBZJBBEDYG4xWob/zTMkk00s3NpmD+hxveYVaOgmib3D9IlVNmgXAsURjKI lqLe2VZywP7zEwGLX0z8g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtjedguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Jan 2023 03:50:48 -0500 (EST) From: Thomas Monjalon To: Alexander Kozyrev Cc: dev@dpdk.org, ferruh.yigit@amd.com, andrew.rybchenko@oktetlabs.ru, orika@nvidia.com Subject: Re: [RFC] ethdev: add template table insertion and matching types Date: Wed, 18 Jan 2023 09:50:47 +0100 Message-ID: <16865748.Ash8RoxBsO@thomas> In-Reply-To: <20221214022110.393410-1-akozyrev@nvidia.com> References: <20221214022110.393410-1-akozyrev@nvidia.com> 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 14/12/2022 03:21, Alexander Kozyrev: > Bring more flexibility and control over both flow rule insertion > and packet matching mechanisms. Introduce 2 new flow table types: > > 1. Allow a user to specify the insertion type used in template tables. > The insertion type is responsible for choosing the appropriate key > value used to map inserted flow rules into a template table. > > Flow rules can be inserted by calculating the hash value for > the pattern or inserted by index via the new create_by_index() API. > The idea of the index-based insertion is to avoid additional matches > and simply execute predefined actions after jumping to the index. I don't understand the idea. Why is it avoiding additional matches? > The insertion to an already existing index is undefined and Why is it undefined? > depends on PMD implementation. An old rule must be destroyed first. > The index cannot be bigger than the size of the table. > > 2. Allow a user to specify the hash calculation function used in template > tables. The hash calculation type is responsible for the calculation of > the flow rule index a packet would hit upon arrival at the table. > > Control over this is useful for applications with custom RSS algorithms, > for example. An application can select various packet fields to serve as > a hash calculation source and jump to the appropriate flow rule location. > The RSS hash result will be used as the index in the table. For the linear > hash function, the mapping is one-to-one and the hash result is the index. > For other hash functions, the index is the hash result module table size. > The RSS hash result can be retrieved via modify_field API: HASH_RESULT. > > Signed-off-by: Alexander Kozyrev > --- > doc/guides/prog_guide/rte_flow.rst | 20 +++++++ > lib/ethdev/rte_flow.c | 24 ++++++++ > lib/ethdev/rte_flow.h | 96 ++++++++++++++++++++++++++++++ > lib/ethdev/rte_flow_driver.h | 11 ++++ > lib/ethdev/version.map | 3 + > 5 files changed, 154 insertions(+) Is there a PMD implementation available on the mailing list? This is required to accept a new API.