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 E8EABA0093; Tue, 8 Nov 2022 12:48:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D6FA5400D4; Tue, 8 Nov 2022 12:48:17 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 2CB574003C for ; Tue, 8 Nov 2022 12:48:16 +0100 (CET) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 9469C66; Tue, 8 Nov 2022 14:48:15 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 9469C66 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1667908095; bh=SSLXbDDtx6Z3orkxdj6hTjm2Z8PNzlORlzdhsg+0GqY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gtFKr+B8wWKTO8Iesf6V5Y6HrYhmbJiJTU/J2DPWU5UE7aCTqrzSlYdT+6jdXEPxx VChkPYq0ULj1VqmSVahY4z8gz/Zy8pHAspJz5kqB8o+XYrN9szcd5Mn1ubyu9M7i6r L+GwkqTXqrEQqOrnYzaTrykkUSw0EzslyXX/O9fE= Message-ID: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> Date: Tue, 8 Nov 2022 14:48:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH v3] ethdev: add hint when creating async transfer table Content-Language: en-US To: Thomas Monjalon Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , Yuying Zhang , Ferruh Yigit , dev@dpdk.org, rasland@nvidia.com References: <5d8d42b2-7011-cb46-7f2c-1b1019c4151e@oktetlabs.ru> <2308337.OYXXYNVTWy@thomas> <6c59c7e9-2b24-095e-53e6-d0f0744d5681@oktetlabs.ru> <23493060.RjEADstKbi@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <23493060.RjEADstKbi@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 11/8/22 14:18, Thomas Monjalon wrote: > 08/11/2022 10:35, Andrew Rybchenko: >> On 11/8/22 12:19, Thomas Monjalon wrote: >>> 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? >>> >> >> Since origin is just a hint which does not impose any matching >> criteria it must be highlighted in example that corresponding >> rules must have some pattern items defining corresponding >> origin. > > Yes we could talk about corresponding rules in the commit message. > > What do you think of the explanations in the doc? I've replied on v4. > >>>> 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. > > >