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 748EC42457; Sun, 22 Jan 2023 21:55:53 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C424400EF; Sun, 22 Jan 2023 21:55:53 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 01855400D4 for ; Sun, 22 Jan 2023 21:55:51 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 756F55C014D; Sun, 22 Jan 2023 15:55:50 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 22 Jan 2023 15:55: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=1674420950; x= 1674507350; bh=pVQTbLOSVo8NPxvMvmnm0J/aaYgiCwsuJuOy0G7dbMI=; b=w mngJrasUFLJSyLkEWsN6TvpjbU48YExvyYXkS6tWON+wwHzPigvokBiFGo82QpOF Ds6MFhi5PmB2v51tvd+jk0xmS6TWbphGHFTDRNoeWHNftOJaGLkNRXzVBQGZvmav ocAxu13A5EqoT2xeLtbH0nOSw7i7XB3QBrL5OnPAm04x1gIhxUg4MdwzFwG/wZUc v6+wh9DxvtGOyFmLlRb5fKzNI3EyVjboy4CyQQFdk0JSKCwb30n0AwNT7GcSo5G7 PZV7JrSzpIXNZH+Cyb6lhZG9akRojoC9tTeQEa8H6AmHYIdiSfMtRvcIWOQtoiCF 5DjZgLfEB4Jpb6HIsvNow== 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=1674420950; x= 1674507350; bh=pVQTbLOSVo8NPxvMvmnm0J/aaYgiCwsuJuOy0G7dbMI=; b=n 5mZ65WNPruqxu935fGYgrIwcZZ7EncGOk9TyQsxERXwZ5LS+lv6tJqKVC8vYKHYD Q+qSfAGJ38Tey+pPA3NfxGzko+tI+v7QaRTZPTLZzvrlR83IO/8zG73aYvcou1KI muKf8ZzUd698KxGSWeNPmscZOCW/4Cb9Eq4lFyJfewinD3WedaSp/SGpr1K1cwtD 4MXB/TUD4q6o3i+BpB/Ew/4TL+Y6uDvAdTGhgasHf9pNVPduLvJpSrqK1yB2zOlY LhR5qAXXjud9/PScrLfwJiARdV/Sa3TeUG0j9cLurveTEyhaBOb8eNEGcBvZQJoG MQhDTBsGnLt6KB2gymuUw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudduiedgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 22 Jan 2023 15:55:49 -0500 (EST) From: Thomas Monjalon To: Alexander Kozyrev Cc: "dev@dpdk.org" , "ferruh.yigit@amd.com" , "andrew.rybchenko@oktetlabs.ru" , Ori Kam Subject: Re: [RFC] ethdev: add template table insertion and matching types Date: Sun, 22 Jan 2023 21:55:48 +0100 Message-ID: <6424586.17fYzF0512@thomas> In-Reply-To: References: <20221214022110.393410-1-akozyrev@nvidia.com> <16865748.Ash8RoxBsO@thomas> 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 21/01/2023 00:06, Alexander Kozyrev: > > 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? > > If you jump directly to an index in a table, you don't need to match anything. > For the regular pattern-based table you must calculate the hash and match on it. I don't get it. I think it would be simpler with an example. > > > The insertion to an already existing index is undefined and > > > > Why is it undefined? > > The behavior is up to a PMD to decide. It is free to replace the rule or throw an error. An undefined behavior of an API makes applications not portable. Why not deciding of a behavior? You are not sure what is best?