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 EB63541BAE; Thu, 2 Feb 2023 13:21:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9186406A2; Thu, 2 Feb 2023 13:21:08 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 0DAED40689 for ; Thu, 2 Feb 2023 13:21:08 +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) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 66E4E50; Thu, 2 Feb 2023 15:21:07 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 66E4E50 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1675340467; bh=0UIwsY9TzWlo07q1AwA7T/9DmB/I0gKNh6mfQNo9DCo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=bTzBVMAmaQvd9k7CVof3wtAPpbJv0Ik7aDkEEg40inxRtxc0zhvlBvi2vWnGtoLnG FPhcDHa5FXVZd3tU9QZCf7R2lWGUVtdVJH+cWAbSzyLnaPDbfF9Y7vlq5zRy39EvGT FA9YopNrFjicWMERtH6fFORjYbbcqOTVBNr5UfrQ= Message-ID: <297c03eb-8111-898d-4f64-d96f2cb1977e@oktetlabs.ru> Date: Thu, 2 Feb 2023 15:21:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation Content-Language: en-US To: Thomas Monjalon , Ivan Malov Cc: Ferruh Yigit , Jerin Jacob , Ori Kam , Nithin Kumar Dabilpuram , Aman Singh , Yuying Zhang , "dev@dpdk.org" , Hanumanth Reddy Pothula , Slava Ovsiienko , Jerin Jacob Kollanukkaran , "david.marchand@redhat.com" References: <20221220200250.2413443-1-hpothula@marvell.com> <5058570.GXAFRqVoOG@thomas> <49cbeb83-1c51-258c-5d1f-35e9cc597674@arknetworks.am> <2202391.PYKUYFuaPT@thomas> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: <2202391.PYKUYFuaPT@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 2/2/23 15:03, Thomas Monjalon wrote: > 02/02/2023 12:55, Ivan Malov: >> On Thu, 2 Feb 2023, Thomas Monjalon wrote: >> >>> OK we are progressing on this topic :) >> >> Indeed we are. >> >>> >>> 02/02/2023 11:48, Ivan Malov: >>>> I apologise, there was a typo in the previous mail: "PMD does >>>> not need this API". Should read as "TESTPMD does not need it". >>> >>> testpmd needs all ethdev API, >>> because its purpose is to test the whole all ethdev API. >> >> Touché. >> >>> >>> Maybe the use of this function is misplaced in testpmd. >>> It should be a specific command. >> >> So.. indeed. A specific command which, as I said, is >> invoked explicitly by the person operating testpmd. >> >>> By the way, what is the driver default if negotiation is not done? >> >> The answer is in the question. It's the driver's default. >> If the driver believes it shall NOT deliver metadata for >> the sake of improved performance, default = all disabled. >> If this delivery is a don't care to performance, then >> the driver might want to enable everything by default. >> >> This decision is made by a PMD maintainer, I take it. > > I think it is better to have the same default for all drivers. > What others think? Of course, it would be better since it would simplify porting apps from one NIC to another. The problem is that some NICs do not require negotiation since corresponding data is always available. If so, the same default should be to provide all Rx metadata by default. However, it would decrease performance for NIC NICs with default settings. (Similar situation is with Rx checksum offload. Some NICs always calculate Rx checksum and always provide results, however, it is not a good reason to require it for all NICs.)