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 7AD89A0093; Wed, 9 Nov 2022 10:03:20 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 33505400EF; Wed, 9 Nov 2022 10:03:20 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 9F130400D7 for ; Wed, 9 Nov 2022 10:03:18 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5939D5C009D; Wed, 9 Nov 2022 04:03:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 09 Nov 2022 04:03:18 -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=fm1; t=1667984598; x= 1668070998; bh=+zrnJ/os9qMXn+IBw4HCxGnBy/2/WXMXt7P1Wsl7cRE=; b=V YsjG9oUS1PPtOmKSk2dm/Q7Tcau+DR3yhgLaQG1H09yHQwT6JkJWRFTlSIVBTeha VG4W2l/w36c/D+bjk/R6UfRtuUOKt9+k9434Q5mU2IuCaam5NL1nn63P/4EMweLU wPA3GuXvTnP1dBfXkNq7wIardpFxbEKeoMlv3amvyimZ/72j9G3W4+gr9bcS10SX m3oWQ1PGh0TAZZRDsthh542RtMkD9od4O8+PgFUJVWIQ8tboTWbbqrmVN4JGpwCq RSwovLGrBwBEpL5Tkzz1ds2FzSyt4cSjZHkxApJL2VBBvSdtnH8Ut7rvdITkGcuC gcGhZFOdvmz7iVbxvTfOg== 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=fm1; t=1667984598; x= 1668070998; bh=+zrnJ/os9qMXn+IBw4HCxGnBy/2/WXMXt7P1Wsl7cRE=; b=a 59zL8exVNWcmKus2Oe8snveLPzzWEWtbNqgsRvEdFhUQEaFq8sQaDwQoGQ0KH7oK Jh+Euc1CRTv0DEEnnMzXJP8QzO4adOJpWlXadFwtox++KPBOE6A/D3HMx+N841i7 Kmf1SNmrenH7O3f8vMLbiW9bhP01K4+nEFsw9fo3t2IFK1TYc046/i13Zx77Hbkd nG6XuHaAwF3CQ5B1hmhTAuZ1aaJlkzU5bhHT4+1PB2DcddUML0AfFU5UnJ1dUNER UA4vM2ZYUbr2og15Nk7bgL01UBAlBEKmi11C4m34TM+XB0UETk9TK6QbhJ05K1eL 9b+H+h+cOosEguny7qAew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedugdduvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 9 Nov 2022 04:03:16 -0500 (EST) From: Thomas Monjalon To: Andrew Rybchenko Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , Yuying Zhang , Ferruh Yigit , dev@dpdk.org, rasland@nvidia.com Subject: Re: [PATCH v4] ethdev: add special flags when creating async transfer table Date: Wed, 09 Nov 2022 10:03:15 +0100 Message-ID: <1708674.pYTLVKaXyH@thomas> In-Reply-To: <7ac25cbb-55ca-b1f3-0729-b46a34ad467c@oktetlabs.ru> References: <1712111.oqx4rD5t72@thomas> <7ac25cbb-55ca-b1f3-0729-b46a34ad467c@oktetlabs.ru> 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 09/11/2022 09:53, Andrew Rybchenko: > On 11/8/22 18:25, Thomas Monjalon wrote: > > 08/11/2022 15:38, Andrew Rybchenko: > >> On 11/8/22 16:29, Thomas Monjalon wrote: > >>> 08/11/2022 12:47, Andrew Rybchenko: > >>>> On 11/8/22 14:39, Andrew Rybchenko wrote: > >>>>> On 11/4/22 13:44, Rongwei Liu wrote: > >>>>>> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h > >>>>>> index 8858b56428..1eab12796f 100644 > >>>>>> --- a/lib/ethdev/rte_flow.h > >>>>>> +++ b/lib/ethdev/rte_flow.h > >>>>>> @@ -5186,6 +5186,34 @@ rte_flow_actions_template_destroy(uint16_t > >>>>>> port_id, > >>>>>> */ > >>>>>> struct rte_flow_template_table; > >>>>>> +/** > >>>>>> + * @warning > >>>>>> + * @b EXPERIMENTAL: this API may change without prior notice. > >>>>>> + * > >>>>>> + * Special optional flags for template table attribute. > >>>>>> + * Each bit stands for a table specialization > >>>>>> + * offering a potential optimization at PMD layer. > >>>>>> + * PMD can ignore the unsupported bits silently. > >>>>>> + */ > >>>>>> +enum rte_flow_template_table_specialize { > >>>>>> + /** > >>>>>> + * Specialize table for transfer flows which come only from wire. > >>>>>> + * It allows PMD not to allocate resources for non-wire > >>>>>> originated traffic. > >>>>>> + * This bit is not a matching criteria, just an optimization hint. > >>>>>> + * Flow rules which match non-wire originated traffic will be missed > >>>>>> + * if the hint is supported. > >>>> > >>>> Sorry, but if so, the hint changes behavior. > >>> > >>> Yes the hint may change behaviour. > >>> > >>>> Let's consider a rule which matches both VF originating and > >>>> wire originating traffic. Will the rule be missed (ignored) > >>>> regardless if the hint is supported or not? > >>> > >>> If the hint RTE_FLOW_TRANSFER_WIRE_ORIG is used, > >>> the PMD may assume the table won't be used for traffic > >>> which is not coming from wire ports. > >>> As a consequence, the table may be implemented on the path > >>> of wire traffic only. > >>> In this case, the traffic coming from virtual ports > >>> won't be affected by this table. > >>> To answer the question, a rule matching both virtual and wire traffic > >>> will be applied in a table affecting only wire traffic, > >>> so it will still apply (not completely ignored). > >> > >> If so, it is not a hint. It becomes matching criteria > >> which should be in pattern as we discussed. > > > > It is not a strict matching because the PMD is free to support it or not. > > It cannot be optional matching criteria. Matching criteria must > be always mandatory. Otherwise application does not know what > to expect and behaviour may legitimately vary on different > vendors. I think you take it in the wrong direction. The idea is not to have it as a criteria. Let me explain again: If an application is using a flow table to manage flows which *always* come from the same type of port (wire or virtual), then the application can give this information to the driver. With this assumption coming from the application, the driver may do some optimizations. Now about what is explained above: If the application gives such a hint but does not respect its own assumption, then confusion happens.