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 64E4F41B90; Tue, 31 Jan 2023 17:18:03 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0312D4067B; Tue, 31 Jan 2023 17:18:03 +0100 (CET) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by mails.dpdk.org (Postfix) with ESMTP id 739B640041 for ; Tue, 31 Jan 2023 17:18:01 +0100 (CET) Received: by mail-vs1-f51.google.com with SMTP id i185so16596877vsc.6 for ; Tue, 31 Jan 2023 08:18:01 -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=Z2/oGynk768vRz6Az16+3czyCw7IUSZDhLqa+rnlzQw=; b=D3vm81WOhSXxj3d0Qi0QcS6Cu9B9mz6fsHDr+Edqql3bN7fPVqk7qFF+GwKxmOH0Tt CCvh7YLYEdvxYGsRzp6ea8Bs5nGaiNiIhGQyZZ43M3ysATTMmiJfjH59MB1NVjlPqIrd nYePSVVHEs1N702YBgxJG1oa/2pI6LPCkHzjZ3NUNikkqu1U+5UYkNu3T9QoHCbq+4kE 4/gj46cm1kPTWdoQYb/PkZqStJ/fqRB623ifb6YQgQ9IkbR1sBMic2EDGNHbGsn5Lo6H jmdUUUwDzt8XGbrE3QNZ1eqP9PDFb7+wHVwAjoEmdbHl6Ti63CEiEe+tccyJehat+2jJ RmIA== 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=Z2/oGynk768vRz6Az16+3czyCw7IUSZDhLqa+rnlzQw=; b=jyQcTeMWRSd5mqGzL3jYXWjW6Ywj7fCDaIiNHjZLP/k/lAd/LDnyuEDOtZ+5or2ZSe nOT/osFLs5S/5BZUFXE4tmO+d0osOqdWxR5HxUiFE6dD5s+Mli5CLc8KBAmh/2SwtPpI wEcO/Fs9qRp3DObAoe5nWyIlldU8v7EI4na7lpv/9U6CfLlykSVeQ7U8gTpiiuFEAFtz h+JX+bpH8XPuR9niNcOF30pV2jKaTcS8KZktND6ocVXuS8llI3iVTiYfbz2XDPUXodhN foE7pJm+Tq6Jp8V6K3oRyVwxZe7mY7SRYufiZ6DU2E+TIcV5v8tB2l4s8OEt2ZbAZna8 D64A== X-Gm-Message-State: AO0yUKWIoDvbIyqpoU9RfgdqPG7WXPl8zHyuYVI0DojE/zKb7h0FxeAW +MN9IC5gRdyWYN6Tvnig4LhvDrVq+QC/stQ2KhY= X-Google-Smtp-Source: AK7set9SirDd2qva3RH3fMIemvSNVo1868VgU9pi0CgWronhGdcbF1vz1NfCq8n85wycF4dJ6LlCNICY89R5/uOJfc8= X-Received: by 2002:a05:6102:d1:b0:3f1:b35:72d2 with SMTP id u17-20020a05610200d100b003f10b3572d2mr1785716vsp.73.1675181880717; Tue, 31 Jan 2023 08:18:00 -0800 (PST) MIME-Version: 1.0 References: <20221220200250.2413443-1-hpothula@marvell.com> <4531200.rE2NhlSrgm@thomas> <13375798.lhuNh5TYOU@thomas> In-Reply-To: <13375798.lhuNh5TYOU@thomas> From: Jerin Jacob Date: Tue, 31 Jan 2023 21:47:34 +0530 Message-ID: Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation To: Thomas Monjalon Cc: Nithin Kumar Dabilpuram , Aman Singh , Yuying Zhang , Ivan Malov , Andrew Rybchenko , "dev@dpdk.org" , Hanumanth Reddy Pothula , Ferruh Yigit , "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 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. > >