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 4B5DCA034C; Wed, 9 Nov 2022 11:50:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 050254014F; Wed, 9 Nov 2022 11:50:54 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 107CD40143 for ; Wed, 9 Nov 2022 11:50:53 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A728C5C01A1; Wed, 9 Nov 2022 05:50:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 09 Nov 2022 05:50:51 -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=1667991051; x= 1668077451; bh=J52FfTFtpKMew3sU4Fwq9KnTd8mr3M2Nhw5kNnMCDCo=; b=T 17G88YkHQcoUji4QfepMNduTPa97w6A61wDiG09Uyk9Q8Njh6HBkJyVKtGrtEDuX 1K4cwUOEp720/a9ZEAn783Hg4Xk8LSIVVQMSxYDfDU/ayYgiluPd7YBvKebpc3WX hab2S/M26d3g7yFCGO5FNadXFUjeqnq6lQNCtCpNPSqERIQdGoDNn02XGy5DyVdk LVYTAvLFlESCn3l7cv9pF+AD87YD/kY6wwm26t400jQdKAWpiKDeHpLBddZEdaFD KqxW9R/gQezPh6RtZPpMlOji0ZFkaLs1aQYEzBwJ/dmETOC0XjIFccGgA4fTbkQD 0SmGg7GeqO/eF3mmqOd/w== 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=1667991051; x= 1668077451; bh=J52FfTFtpKMew3sU4Fwq9KnTd8mr3M2Nhw5kNnMCDCo=; b=w l+qmWFanGpxa4SQ1YT8avQi3QofVkueCEkYhkZsy2tjOH9xhv8pbU4Jn2MRVq8bQ gZycuh84pV0ivGhrJDOtYh11mSrdlocP24tIqdzH9rMhaJM/Af+B7nD9s5v5Uq8j AhdPTIiP0Gk7LbKGL4pmoWU00iZ3LF+GhCWCwvRv53qrpRle5r2YuENU7pDcyz5u nhYwizHRdep7l9/5uOtl/jvUfo0g6dbyAckl35kPdTt8drTN2wrIOgF1MCGRVuO0 sGDiGEeLn0r7Pm0VfWWXK6dP0Rjf5/ZL9fvITPEn2DPLlupNBPDqxDeRWK/NNqLV lnwae6TvYe4RYp22GFzOw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedvgddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 9 Nov 2022 05:50:50 -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 11:50:48 +0100 Message-ID: <6951385.dE46n4Xy2H@thomas> In-Reply-To: <0e3fc6fc-40e0-bca3-0d18-c426160186e6@oktetlabs.ru> References: <1708674.pYTLVKaXyH@thomas> <0e3fc6fc-40e0-bca3-0d18-c426160186e6@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 10:36, Andrew Rybchenko: > On 11/9/22 12:03, Thomas Monjalon wrote: > > 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), > > What does guarantee it? Is it used a jump-table and jump rule > must guarantee it? Or has pattern corresponding unit? > > It is very thin ice and I'm ready to bet money that finally > it will be used as a matching criteria intentionally or not > intentionally. Simply because it works as matching criteria > on, for example, Mellanox. I.e. if rules from table with > corresponding hint are programmed to HW which applies these > rules on traffic from wire only - effectively it is a matching > criteria. And it will be used this way. And it will be not > portable to other HW which does not support the hint. > So, we're making an API which is very easy to misuse if not > to say more. I completely understand your concern (I have same). In other words, if the application misuse the hint, it will become not portable. That's why I made sure to highlight such misue consequence in the API comments. > You know better if it is OK or not to rely on liable users > in the case of DPDK. I do not rely on users, and I don't want to block innovation. That's why I want to make sure all is explained and clear, so freedom comes with responsibility. > It would be much safer if we do not rely on application in this > case, introduce a new pattern item to specify origin and > require PMD to check that pattern has either a new pattern item > or corresponding REPRESENTED_PORT/PORT_REPRESENTOR pattern > item. Safer is not often compatible with fastest :) > I realize that my concerns could be not valid and it is just > a paranoia. Just add your ack and let's move forward. Let's wait for other opinions. > > 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.