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 33A93A0032; Mon, 15 Nov 2021 18:33:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 16EEE41157; Mon, 15 Nov 2021 18:33:18 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 8E76C40141 for ; Mon, 15 Nov 2021 15:15:35 +0100 (CET) Received: by shelob.oktetlabs.ru (Postfix, from userid 122) id 6F6FB7F500; Mon, 15 Nov 2021 17:15:34 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shelob.oktetlabs.ru X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_DISCARD, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from bree.oktetlabs.ru (bree.oktetlabs.ru [192.168.34.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPS id B7ABA7F4FA; Mon, 15 Nov 2021 17:15:28 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru B7ABA7F4FA Authentication-Results: shelob.oktetlabs.ru/B7ABA7F4FA; dkim=none; dkim-atps=neutral Date: Mon, 15 Nov 2021 17:15:28 +0300 (MSK) From: Ivan Malov To: Ferruh Yigit cc: David Marchand , Andrew Rybchenko , Thomas Monjalon , Ivan Malov , dev , Ori Kam Subject: Re: [dpdk-dev] [PATCH] ethdev: fine tune error reporting in pick transfer proxy API In-Reply-To: <815a9fc9-747f-46f8-c9cf-766fa71a9ecb@intel.com> Message-ID: References: <20211027090003.14556-1-ivan.malov@oktetlabs.ru> <32956056-8804-046c-da59-119a6c378dd3@oktetlabs.ru> <2115605.bGoMZ7lrYc@thomas> <4cf45c3f-47df-b6c9-7f9e-2ce996878e45@oktetlabs.ru> <815a9fc9-747f-46f8-c9cf-766fa71a9ecb@intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Mon, 15 Nov 2021 18:33:16 +0100 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 Wed, 10 Nov 2021, Ferruh Yigit wrote: > On 11/2/2021 5:04 PM, David Marchand wrote: >> On Tue, Nov 2, 2021 at 4:59 PM Andrew Rybchenko >> wrote: >>>>> IMHO, spamming of testpmd logs in described case should be fixed >>>>> in testpmd itself to avoid logs in the case of ENOTSUP. That's it. >>>> >>>> I think we should not call this API in testpmd >>>> if not doing rte_flow transfer rule. >>>> >>> >>> Since testpmd does not pursue top flow insertion rate etc, >>> I tend to agree. For debugging purposes (testpmd main goal) >>> the best way is to pick proxy just before usage without any >>> caching etc. >> >> +1. >> > > +1 to not call this API when not doing rte_flow transfer rule, > and get rid of this testpmd logs.. > Hi all, I apologise for the delay. These arguments make sense. Thanks. However, the idea to hide the proxy port request inside flow command handlers might be wrong in fact. It is too much code churn. And it is easy to overlook this part when adding new indirect action handlers that are also suited for use in transfer flows. To code maintainers, it is very vague. Now you mention it, testpmd is indeed scenario-dependent. Its workings should be explicitly controllable by the user. That means, the proxy thing should be exposed via an explicit command: "show port flow_transfer_proxy". As testpmd is a debug tool, it should simply do what the user says. Suppose, the user wants to create transfer flows. They realise that doing so may require proxy. Hence, they request the proxy and then use the resulting port ID in all commands which have something to do with transfer flows. Very robust. And, of course, this way, the request is done only when the user needs it, and spamming the log is also gone. Let the user query the proxy themselves, and things become simple. Please vote in favor of my motion. It will not break anything. Right now, in this release cycle, nobody supports the proxy thing, so the existing flow use cases should work as normal. Opinions are welcome. -- Ivan M.