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 E5816A0032; Mon, 15 Nov 2021 16:09:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BAA9641144; Mon, 15 Nov 2021 16:09:19 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id B3B9C41144 for ; Mon, 15 Nov 2021 16:09:18 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2A97E5C0066; Mon, 15 Nov 2021 10:09:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 15 Nov 2021 10:09:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= vQ4vmK37D4zbES3TTLBPY4c2f5+eK9NQhd6oGHnWK2k=; b=fUcsLcWXCnsJP6fp 6JHhbN6Tir2GTjzOb5gaFf949nOOB6qtNa7R9LrLfbeMbvRavEa2V0exL1+i0W6u FXjk7S2r1q5rwf/ooYbyN78WLvP8tCUOpddu0jIcXjjVMXtLXEAPYUr0w3s69hhf ibU9w8pYnksAdwWu5qjXhXapN7swc7Ughm8iN3OvP0Z63hQScQRZJqNcj2cBtQ3C 7B+4XJur70hwEYiixJXxdg9TxSqnpCP5a9jr7aUE0TURPVE7hrVhVPMq+2M9fMGi TWEwk9O6HmW63fPsSMPPi6clSNFNCBMyni5HP2i1+NFm8Lp3heYptPSmp1yM3eWq oXH/ug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=vQ4vmK37D4zbES3TTLBPY4c2f5+eK9NQhd6oGHnWK 2k=; b=E3646aa5BgQC4ZjTETllzlYXuqSUyn7khT2Kk6p/c5fG33RRF7CWJCUe0 u5s/zXUN4egbBvV1FzKaOI2b7GmF9q+dCc+Vb7vyMch9SB3x+i2PwfV9nOlBXTvO mRPtZSqzgaO4sGy/iCaok0Y/89+ySNGWA1hHoSBlo2lNLMsz3NgvnCqwxNhz31EI XrFtm2H1HyXqrFv8mwZL+rGuaMSRKVsO8VfBPvUEr0GV78DOXna4ocShE4OGFuGd ehu5V+whMD/xvn+oS+PFcFYfjQmd0arbeuiDcvJxQGXeJeDmJnfZx98Y+hk1Sw5Y 4vBSt6J0SOOSRUdXJiZkf4NFrlG3Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrfedtgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Nov 2021 10:09:15 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit , Ivan Malov Cc: David Marchand , Andrew Rybchenko , Ivan Malov , dev , Ori Kam Subject: Re: [dpdk-dev] [PATCH] ethdev: fine tune error reporting in pick transfer proxy API Date: Mon, 15 Nov 2021 16:09:14 +0100 Message-ID: <4177995.KZ5Ilm2TE0@thomas> In-Reply-To: References: <20211027090003.14556-1-ivan.malov@oktetlabs.ru> <815a9fc9-747f-46f8-c9cf-766fa71a9ecb@intel.com> 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 15/11/2021 15:15, Ivan Malov: > 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. I'm fine with this proposal.