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 E801E41B9B; Wed, 1 Feb 2023 09:53:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 946EE406A2; Wed, 1 Feb 2023 09:53:54 +0100 (CET) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) by mails.dpdk.org (Postfix) with ESMTP id B4DE54021F for ; Wed, 1 Feb 2023 09:53:52 +0100 (CET) Received: by mail-vk1-f170.google.com with SMTP id l129so8751071vkh.6 for ; Wed, 01 Feb 2023 00:53:52 -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=SPwU2aKcEsCkk3m8RSPaEQKlnWGvHpCMRxVWw19ZG+8=; b=o72p12rlJ6QUKAvAHebRvQ8zRSICOXLlHnQwmJLnbycddGRKN+lvUsJ9vvKNt9BtUW /seDe9t+wJ/82kmFmUl+b+u/G+U/zY1mLPOcyHIZAcLiO5KUPylSfgifU7fwfPce7JZA RmcagNV6mvrJUPQp2z/H4TGbzzTXXP69WOi43AkGA8qdd5NfcNQiMSUalc0FVgnzLcgi 6uSdaH45UebjocpJse7UafaITye6J19KlFXJ/2qLlqg3kC3bCCHhPG3sdI71ANkvdEz9 i822mnmwjZsMZteOHKhfAz+VcAwwmoMBN/ajAEfrh7jPxoM4VWkPWVVdu6lAL07IP917 1Hvw== 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=SPwU2aKcEsCkk3m8RSPaEQKlnWGvHpCMRxVWw19ZG+8=; b=xn/d7kRkcwou7hcnwAK1j1NUCWBLRyO09q8xsHPXokFvYOoqMNiNiVvgXwi6SjEVSw ST6p9F7rCAXUO1OdlDUXroC/nP6DvKC768ICaxX0cqGNudYJa5q++RADmKWMoT1t55YK wn61ozwTvHG7RPFGtwBQiThtsjR6vWnynr9W9q6SteTPB9KVbuEQ9ObVFpeibXlom2vQ Eh7i33FOgRupYi/AFDSTKQHlZ+7jF3Bzhr6c+zQlIP6QLG8P7V9PoumbBfHXu35KWZ0t v5HCblsN6r2rPpxgk1mzHW0OIlVegzsbCUjisqTLrjldkObRLoxVBnmn6CCwM0jXZtyW Mt4A== X-Gm-Message-State: AO0yUKUhQ6wdTsyzt8+C7JWRtZD7efq2MTq9/90pOgwesXhk6qvUS65C WlszLolfSD7Hd+YQgTf58ImpbEW30kZfwWhZrJU= X-Google-Smtp-Source: AK7set8TFskL8xnhbX/lC3oM6A07AD1qNQRbmeT69AsmMvg5D8WQ0e1PmmAh7duylXHOomRKmFtlnOuxI9l+N/zuJAE= X-Received: by 2002:ac5:cbf8:0:b0:3d5:d30f:81c2 with SMTP id i24-20020ac5cbf8000000b003d5d30f81c2mr212885vkn.14.1675241632007; Wed, 01 Feb 2023 00:53:52 -0800 (PST) MIME-Version: 1.0 References: <20221220200250.2413443-1-hpothula@marvell.com> <13375798.lhuNh5TYOU@thomas> <837604649.0ifERbkFSE@thomas> <7f3158cd-bdea-4771-6e74-280ddf838749@oktetlabs.ru> In-Reply-To: <7f3158cd-bdea-4771-6e74-280ddf838749@oktetlabs.ru> From: Jerin Jacob Date: Wed, 1 Feb 2023 14:23:25 +0530 Message-ID: Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation To: Andrew Rybchenko Cc: Ivan Malov , Thomas Monjalon , Ivan Malov , Ferruh Yigit , orika@nvidia.com, Nithin Kumar Dabilpuram , Aman Singh , Yuying Zhang , "dev@dpdk.org" , Hanumanth Reddy Pothula , "viacheslavo@nvidia.com" , 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 12:46 PM Andrew Rybchenko wrote: > > On 2/1/23 09:10, Ivan Malov wrote: > > Hello everyone, > > > > Since making automatic, or implicit, offload decisions does > > not belong in testpmd responsibility domain, it should be > > safer to avoid calling the "negotiate metadata delivery" > > API with some default selection unless the user asks to > > do so explicitly, via internal CLI or app options. > > > > With that in mind, port config ... sounds OK. > > > > PMDs that support flow primitives which can generate metadata > > but, if in started state, can't enable its delivery may pass > > appropriate rte_error messages to the user suggesting > > they enable delivery of such metadata from NIC to PMD > > first. This way, if the person operating testpmd > > enters a flow create command and that fails, > > they can figure out the inconsistency, stop > > the port, negotiate, start and try again. > > > > As for non-debug applications, their developers shall > > be properly informed about the problem of enabling > > delivery of metadata from NIC to PMD. This way, > > they will invoke the negotiate API by default > > in their apps, with the feature selection (eg. > > MARK) as per nature of the app's business. > > > > This API should indeed be helpful to some PMDs with > > regard to collecting upfront knowledge like this. > > At the same time, should be benign to those PMDs > > who do not need this knowledge and can enable > > delivery of metadata right when inserting the > > flow rules. So I hope the API does not create > > too much discomfort to vendors not needing it. > > > > Thank you. > > > > On Wed, 1 Feb 2023, Thomas Monjalon wrote: > > > >> 31/01/2023 17:17, Jerin Jacob: > >>> On Fri, Jan 27, 2023 at 8:31 PM Thomas Monjalon > >>> wrote: > >>>> > >>>> 27/01/2023 11:42, Nithin Kumar Dabilpuram: > >>>>> From: Thomas Monjalon > >>>>>> 27/01/2023 06:02, Nithin Kumar Dabilpuram: > >>>>>>> From: Thomas Monjalon > >>>>>>>> Ferruh is proposing to have a command "port config ..." > >>>>>>>> to configure the flags to negotiate. > >>>>>>>> Are you OK with this approach? > >>>>>>> > >>>>>>> Yes, we are fine to have such command to enable and disable the > >>>>>>> feature > >>>>>>> with default being it disabled if supported by PMD. > >>>>>>> Is default being disabled fine if the feature is supported by a > >>>>>>> PMD ? > >>>>>> > >>>>>> I think the default should be enabled for ease of use. > >>>>> > >>>>> Since testpmd is used extensively for benchmarking purposes, we > >>>>> thought it should have minimum features > >>>>> enabled by default. The default testpmd doesn't have any Rx/Tx > >>>>> offloads enabled(except for FAST FREE), default > >>>>> fwd mode being "iofwd" and the Rx metadata is only referenced when > >>>>> dumping packets. > >>>>> > >>>>> > >>>>>> Do we have similar features disables by default? > >>>>>> I mean do we know features in testpmd which require a "double > >>>>>> enablement" > >>>>>> like one configuration command + one rte_flow rule? > >>>>> > >>>>> Spec itself is that way i.e "RTE_FLOW_RULE + > >>>>> RX_METADATA_NEGOTIATE(once)" > >>>>> > >>>>> Isn't it enough if > >>>>> > >>>>> #1 We have enough print when rte_flow is being create without > >>>>> negotiation done and ask user to enable rx metadata using > >>>>> "port config ..." > >>>>> #2 Provide testpmd app arg to enable Rx metadata(for example " > >>>>> --rx-metadata") like other features to avoid calling another > >>>>> command before rte flow create. > >>>> > >>>> I'm not sure what is best. > >>>> I will let others discuss this part. > >>> > >>> IMO, enabling something always defeat the purpose to negotiate. IMO, > >>> someone needs to negotiate > >>> for a feature if the feature is needed. I think, the double enablement > >>> is part of the spec itself. In case, The PMD > >>> drivers won't like double enablement, no need to implement the PMD > >>> callback. That way, there is no change in the existing flow. > >>> > >>> The reason why cnxk driver thought of leveraging negotiate() feature > >>> so that it helps for optimization. e.s.p > >>> function template for multiprocess case as we know what features > >>> needed in fastpath upfront. > >>> > >>> If there still concerns with patch we can take up this to TB decide > >>> one way or another to make forward progress. Let us know. > >> > >> Ferruh, Andrew, Ori, Ivan, what is your opinion? > >> Let's progress with this patch to make it in -rc1. > > As I understand all agreed that we need testpmd command to > control negotiated Rx metadata. May be even command-line > option would be useful. > > So, remaining question is what should be the default value in > testpmd. Note that it is just testpmd question since default > value in an abstract application is nothing negotiated > (if I'm not mistaken). > > The key advantage of the current behaviour is to avoid > "double-enabling" in testpmd. It preserves behaviour which > we had before before the API addition. It is a strong > argument. Basically it puts the feature into the same > basket as FAST_FREE - need an action to run faster. I think, there is a disconnect here. FAST_FREE is enabled by default. i.e We don't need any specific action to run faster. To align with performance test application, by default the configuration should be run faster. User needs to give explicit configuration to allow more offload or the one causes the mpps drops. IMO, That is the theme followed in testpmd. > I see no problem in such approach. > > The key disadvantage is the difference in testpmd and > other applications default behaviour. > > I'd look at the feature in the following way: > if an application theoretically wants to use > USER_FLAG, USER_MARK or TUNNEL_ID it must negotiate > corresponding Rx metadata to ensure that the feature is > available and HW is informed that application may need it. > Since testpmd supports corresponding flow API actions and > flow tunnels, it tries to negotiate it by default, but do > not fail if the negotiation fails. > > So, I'd would vote to keeping the default value as is. >