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 80C6741B81; Mon, 30 Jan 2023 15:47:09 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6D9F040DFB; Mon, 30 Jan 2023 15:47:09 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id B67ED40DF6 for ; Mon, 30 Jan 2023 15:47:08 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0926C5C0250; Mon, 30 Jan 2023 09:47:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 30 Jan 2023 09:47:08 -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=1675090028; x= 1675176428; bh=Jvyz7cswhmVCdwqdtrnIknnTDOEPf53qFF+WUBiFuVw=; b=h OI3M+qUcs1B3pQawR3AczdKfmv6kAIJDHCKdiZpSmmy+k6aTzDSKtMLtBD4Sbssm Ocg6dQuwLprUz9oVCtJ6S5csEpSCdcO9rxt9tfus9bLHEupezAE85+zaN5m/L9Tp KPHKV9W87+0Vik/Zne2goDYRcIA4Bhng1VZeIlY/rMG5hn/cSN1CehLKX8+UTy33 8gTMGxFVoZfLZx3/NfFMBunU6jiLpuIxhDKOMS7YIT2oz0nhc8DfSyBjDycXOte4 xIxheSltxzGvzz4hc2V29NJ9zHjGLDZpZYyvk95y3jWo16LfHg6lY0saKP2ndgxn ybcxBUuYbYKrWXCM7pWgg== 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=1675090028; x= 1675176428; bh=Jvyz7cswhmVCdwqdtrnIknnTDOEPf53qFF+WUBiFuVw=; b=s mM3tVH97QatUngbBegrEA3QitytjZOD3uQxiqhL6vM1ozslw0ExkMkPspjP2O1pL wCurDozR1K++A+713VBWuhReQ/EVQDQuYKFeW/dz1uXVfKs5S7qKDRf/+936bfr8 EtvuznGk3O8ZfB9gjqvZ+5acqDLKk7mZmMyJZakRZD8yLqWhswquSdZr4zVS0ymP +CzNmEbH/Ab350B/pPGiREvYW29eBBZoMVD2/aW6mwwPqrwRlt6LkUFsOcOq9NMq 5Pi2rInBIkgWYIwvVDY3DH8lpNq/COW3WA7vOa79aO2MYfefucx0ocWEw50iH1KX QIk3BBYhfJXXzEjhzrEOw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefvddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 30 Jan 2023 09:47:06 -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: Mon, 30 Jan 2023 15:47:03 +0100 Message-ID: <3744969.hUukIMtRk4@thomas> In-Reply-To: References: <20221214022110.393410-1-akozyrev@nvidia.com> <6424586.17fYzF0512@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 23/01/2023 23:02, Alexander Kozyrev: > > 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. > > This is how the regular pattern-based table works: > you calculate hash on 5-tuple, go to the table entry with the corresponding hash, > check if there is a collision and search for the proper entry if so, execute actions. > Index-based table: > take an index value from a specified field, go to this index, and execute actions. OK, please make sure the explanation is clear in the patch. > > > > > 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? > > We don't want to restrict a PMD behavior here. > Personally, I would prefer throwing an error in this case. > Do you think returning EEXIST is better? I don't know what is best. At least you can define an error EEXIST if the PMD forbids it, and no error if the PMD replaces the rule.