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 D1B7DA0540; Tue, 8 Nov 2022 10:19:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 65171410EA; Tue, 8 Nov 2022 10:19:38 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id EDA58400D7 for ; Tue, 8 Nov 2022 10:19:36 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A7A0C5C00B3; Tue, 8 Nov 2022 04:19:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 08 Nov 2022 04:19:35 -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=1667899175; x= 1667985575; bh=qtAmUStMXWPd4+bj8Os3itCsKTtnkZ2emHl2hFg1s0Q=; b=Q L5/pwhyZafGNGrJ3f4ToYBjaijLWN6P7GXxBHbf5BQGVucdcrmwfb2fDBMqU31KN 7Ngf9eXkQZNcKFwzRn3TyFlIPKyX0ZD4h7BuDXCM5qF/8fvKMgbhGG/OIziuq5gs EPXWk06yPcrGLrgaaWRHmxY/cl3qGTD5UeL2cTONQFcqvKh3t3ijKxzEduryWBQv xZ/2vyFSlawRGW7dDynJv7lYY/bNPBXg7r6af1M8NNr6SbBfPf4fBRj+e2OTypN0 g06U9oaE7n9ypRrOwepJOsg0SxKyfTpEl6ikq9cIiyb9wxCEBdGvOo28NXFSzHEv SvyygQVXXQXmIx7zFTYYg== 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=1667899175; x= 1667985575; bh=qtAmUStMXWPd4+bj8Os3itCsKTtnkZ2emHl2hFg1s0Q=; b=R Dpd5Buuqzy1bgrREmk3yz5Rw60tWu0TUI3yaLDjoFdWkL9HugTsczJhCVJazctO8 8acBpWD8GByI+76Y0GqxHE6McQh5JuijhhlshLs2EJRKJEVWvTWZSyAou3T9NAyG i14W38ktRunk402sYpzM/Zdtzj4d6Mk3j9UEBTN7sA81m5Q9uCqIsBjPHfGo0IO/ u3rXuwhwKxvqj/qrcSGf9EZ9EgJ9k/Snib7P4nBv21qDE+9yh7sfhzC7DC01S3Gt 62aagbCB+6fr8jW2mDFmsEFwO0gH1Mjp4K4It/YRzUW9rweMDxAgkFKbAV/RNYbj 3WYaqS4tKXU4ClMCu/wsA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Nov 2022 04:19:34 -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 v3] ethdev: add hint when creating async transfer table Date: Tue, 08 Nov 2022 10:19:32 +0100 Message-ID: <2308337.OYXXYNVTWy@thomas> In-Reply-To: <6ec3f733-6370-d90f-b6b6-3eaceec7d0b2@oktetlabs.ru> References: <5d8d42b2-7011-cb46-7f2c-1b1019c4151e@oktetlabs.ru> <6ec3f733-6370-d90f-b6b6-3eaceec7d0b2@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 06/11/2022 11:02, Andrew Rybchenko: > On 10/4/22 11:31, Andrew Rybchenko wrote: > > On 9/28/22 12:24, Rongwei Liu wrote: > >> The transfer domain rule is able to match traffic wire/vf > >> origin and it means two directions' underlayer resource. > >> > >> In customer deployments, they usually match only one direction > >> traffic in single flow table: either from wire or from vf. Customer deployment is not an argument. > >> Introduce one new member transfer_mode into rte_flow_template_table_attr > >> to indicate the flow table direction property: from wire, from vf > >> or bi-direction(default). The origin is not a direction. We should update this sentence. > >> It helps to save underlayer memory also on insertion rate, and this > >> new field doesn't expose any matching criteira. Should be reworded. > >> By default, the transfer domain is to match bi-direction traffic, and > >> no behavior changed. This sentence is confusing, it should be removed. > >> 1. Match wire origin only > >> flow template_table 0 create group 0 priority 0 transfer wire_orig... > >> 2. Match vf origin only > >> flow template_table 0 create group 0 priority 0 transfer vf_orig... This testpmd example needs to be introduced with a sentence. > > Since wire_orig and vf_orig are just optional hints and not > > all PMDs are obliged to handle it, it does not impose any > > matching criteria. Yes > > So, example above are misleading and you > > need to add pattern items to highlight that corresponding rules > > are really wire_orig or vf_orig. This is template table creation, so I don't think there is more to add. What do you have in mind? > I'm sorry, but I still don't see how it is addressed in v4. I think the documentation in v4 is pretty clear. Do you see something in the doc which is confusing? The commit message needs rewording though.