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 ED4F641B9F; Wed, 1 Feb 2023 14:48:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AA7214021F; Wed, 1 Feb 2023 14:48:46 +0100 (CET) Received: from mail-vk1-f172.google.com (mail-vk1-f172.google.com [209.85.221.172]) by mails.dpdk.org (Postfix) with ESMTP id 3955D4021D for ; Wed, 1 Feb 2023 14:48:45 +0100 (CET) Received: by mail-vk1-f172.google.com with SMTP id v5so9079547vkc.10 for ; Wed, 01 Feb 2023 05:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OqLNdQvTX5HAQB/FJ0PExvjmdOHLR4hQkvIF310eOug=; b=X5gC2STMSXa/HpaqIQDjr33mStMKXH12alFyBZVRtm+w3HtLvkjLXSHEB/EVocBPVJ CABmcIDl7vZMmOaBRlLhD/nX5rxNaJHoHehvmynzD0Shqg/yavjc5QF/7ipKBX9EbrNw sorAUK0nA4Ci/VCQlnjR/pK2p+NDW2Bj8zzokc8OnfAF3ctrU1AwxNB9sr00XdpxeSoN LLvmkEcn8MMDCmXwpMPZZeimV+yabdKG/gVhttqOip4a53+ZC4LfXSvlQ5UcQA3kybIw QGxzITJjRRw+CfIums9HgrVe1G8r6ehMqTHTK76V995vohhVNvDfd6OrshBMUVjGbnqW 4SAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OqLNdQvTX5HAQB/FJ0PExvjmdOHLR4hQkvIF310eOug=; b=XX1wTK5s7LNm+kb4e8sqWGqkwDOk+C6NGy7lsOWrC0rGR2+y6/D7aHTK7++OjRFo7F n/Sv/SEJVKKOk4FQlfljbDpQuL1TvmqTArdnQZ5m034Ly+RPmPcqOolxyGnMqpCHo26E uTl4pJwaL9fKuMR8/+21F0+2RhB7qTbozudj639m1yTUwkGi/MqPT/UjH7dTG/rv2Qyw cCSzZIzbfkk/DS36i6mq3vvzPgEF5oeyoAgaMcovkVlz/d/Wfc9lmuZzfWXjaKd5f1ti 9DvhUeG5o+3KPmbjBSLF7KiPhzTfi6OPlhwMDUQNDOubuIQKpXavxYD/xOMaFfA+j05e oKtw== X-Gm-Message-State: AO0yUKWfokjFSWLofy8pgVQMW009/vHV2SIdE4q++yNNp0YYR5PVmj1i WEe/ajOH0lzUXANVMi615xnhBjE31PZh9CBvtZc= X-Google-Smtp-Source: AK7set9BOK7XLtlmAQf7LrQctkrIFAxD3Z8XWPtpNBeUVQpmM9l2MQglIc4frMJLaxk1da19nXp1RhIBP6escfMPWVY= X-Received: by 2002:a05:6122:637:b0:3ea:3757:a3c with SMTP id g23-20020a056122063700b003ea37570a3cmr320951vkp.20.1675259324534; Wed, 01 Feb 2023 05:48:44 -0800 (PST) MIME-Version: 1.0 References: <20221220200250.2413443-1-hpothula@marvell.com> <98a80c20-a5e4-deea-f7dc-c6aa5d52800b@oktetlabs.ru> <2490780.4XsnlVU6TS@thomas> <22a65100-bee8-1726-6e27-14b9028a29d4@amd.com> In-Reply-To: <22a65100-bee8-1726-6e27-14b9028a29d4@amd.com> From: Jerin Jacob Date: Wed, 1 Feb 2023 19:18:17 +0530 Message-ID: Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation To: Ferruh Yigit Cc: Thomas Monjalon , Andrew Rybchenko , Ori Kam , Ivan Malov , Nithin Kumar Dabilpuram , Aman Singh , Yuying Zhang , "dev@dpdk.org" , Hanumanth Reddy Pothula , Slava Ovsiienko , Jerin Jacob Kollanukkaran , "david.marchand@redhat.com" Content-Type: text/plain; charset="UTF-8" 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, Feb 1, 2023 at 5:06 PM Ferruh Yigit wrote: > > On 2/1/2023 11:15 AM, Jerin Jacob wrote: > > On Wed, Feb 1, 2023 at 4:35 PM Thomas Monjalon wrote: > >> > >> 01/02/2023 11:58, Andrew Rybchenko: > >>> On 2/1/23 13:48, Jerin Jacob wrote: > >>>> On Wed, Feb 1, 2023 at 2:59 PM Andrew Rybchenko > >>>> wrote: > >>>>> Frankly speaking I don't understand why default value is so > >>>>> important if we have a way to change it. Reasons should be > >>>>> really strong to change existing defaults. > >>>> > >>>> The only reason is, typically testpmd will be used performance > >>>> benchmarking as an industry standard. It is difficult to tell/educate > >>>> the QA or customers > >>>> that, "BTW if you need to get better performance add more flag to > >>>> testpmd command line". > >> > >> I disagree. > >> When you do performance benchmark, you tune settings accordingly. > > > > IMO, We tune the system resources like queue depth not the disabling > > features for raw performance. > > queue depth etc people know to tune so it is obvious. What is not > > obvious is, testpmd only > > negotiated some features by default.I am not using that feature, hence > > I need to explicitly > > disable it. > > > > When 'rte_eth_rx_metadata_negotiate()' API is NOT used at all, and I > believe that is the case for almost all applications since API is a > relatively new one, PMD default behavior should be to enable Rx metadata > flow rules, in case user requests them later. > > So, enabling all in application is same with not calling the API at all. > > In this perspective, disabling Rx metadata is additional > optimization/tuning that application can do if it is sure that Rx > metadata flow rules won't be used at all. > And API is more meaningful when it is used to disable Rx metadata. > > I think it is reasonable to enable all Rx metadata by default in testpmd > with a capability to disable it when wanted. > > OR > > May be we don't call 'rte_eth_rx_metadata_negotiate()' API by default in > testpmd, it is only called when it is requested explicitly from user, > enable or disable. Second option looks good to me. When 1) user request for action which is needed negotiate(), AND 2) rte_eth_rx_metadata_negotiate() != ENOSUP then, testpmd print a warning that need to enable rte_eth_rx_metadata_negotiate(). > > > >> > >>>> To make that worst, only some PMD needs to give the additional > >>>> parameter to get better number. > >>>> And also, testpmd usage will be treated as application modeling. > >>>> > >>>> Since this feature only used on sfc and cnxk driver, What is the > >>>> situation with sfc driver? > >>>> Keeping it as negotiated and not use the feature, will impact the per > >>>> core performance of sfc or > >>>> is it just PCI bandwidth thing which really dont show any difference in testpmd? > >>> > >>> Yes, sfc could run faster if no Rx metadata are negotiated. So, > >>> it is better to negotiate nothing by default. But it is always > >>> painful to change defaults. You need to explain that now you > >>> need to negotiate Rx metadata to use mark, flag and tunnel offloads. > >>> Yes, it will be required on sfc and cnxk only. > >>> As an sfc maintainer I don't mind to change testpmd defaults. > >> > >> If we change testpmd defaults to "do nothing", > >> then we should disable MBUF_FAST_FREE as well. > > > > if you see MBUF_FAST_FREE, it does nothing. Actually, > > !MBUF_FAST_FREE is doing more work. > > > > > >> > >> >