From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6476FA04C3; Fri, 22 Nov 2019 14:32:41 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1CD652C08; Fri, 22 Nov 2019 14:32:40 +0100 (CET) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id DF3F0235 for ; Fri, 22 Nov 2019 14:32:38 +0100 (CET) Received: by mail-il1-f196.google.com with SMTP id u17so6943534ilq.5 for ; Fri, 22 Nov 2019 05:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5z39XVa7uEiPA/ZqrbYli4y9MRCznlCPWBUGV1zbVuc=; b=ZSMw4nzk76oAoH30yqdnPQhZpaba3nHOjjwD0aEnocAd4Vw2LUMGvicPVoCuct0opw IcW4czyYe/gn1zB0StIIZEISfb5OLEmAcyeSA66bBwd6cVoF4Cg/XNw8eUNXxgWSoWrj WQNqsqO6n415WumupTLLrsFQokbnyCueidUdhRmoxVa/Km1Oa/tOSkK7n/hL1LYfxRZz AlRkqQqkL5+JQa9MqUJlGLCPVMEU6mWoxV0nJXYJEQdZAoULvqpRnctRLnGmiCGHhvXr a9U5NO6RGyGbpYyEiQVJBGtS8NqxJ12Lnz1yNZR1aB6/Vs+BrnC1ACLsBwTz38kEJ2tL UXmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5z39XVa7uEiPA/ZqrbYli4y9MRCznlCPWBUGV1zbVuc=; b=SvGJp8b08tY1/vxoO8SX/61USGCYfe8g456cHm/XmJDEZW16YuK8jKEDGyE5qxFYmF N4QcTBXHnGQSX8ysh5hjQtbI2hfOxfykf14UbgM+4gka/iY2j1MwFR8kJ51xy3hSnD/X gmCpftk4ARmSuq1t+RvFe5afT9N3/fFRSrq9I0HKyjwP/KjlL75fVfQnm910HljjJG1D E883nWUKfkCiAzulycafaaovOt2UQkD3kl8zBJ7486+gLcGwazARtFEU+ssRCWSlYZUG GlcSD24W2EISBNB5y1si806Wv5DM4Lny/vzt7UltWmYnLGlZB8BJ66zO8TyLg64oNmCI 1KpQ== X-Gm-Message-State: APjAAAWjBNJbwqFdOBuZbJAozmJ+E2d3tDeGdT/P9MN4+NfLxtrK4Hk+ N/TXx9n5f80gHEB6yh83bHM2+iqpGJCozFxaZXs= X-Google-Smtp-Source: APXvYqyJs+0jaN2uPeJb5JtGUbZsXRSxcGYWagIhIad4Bmd8u0nA8MAyPTfAwNAg/rKNAy0xab0i/H5CZi0jXmWjtMc= X-Received: by 2002:a92:aa48:: with SMTP id j69mr16941182ili.162.1574429557886; Fri, 22 Nov 2019 05:32:37 -0800 (PST) MIME-Version: 1.0 References: <1574165145-23960-1-git-send-email-arybchenko@solarflare.com> <3628380.zSPWDRPf13@xps> <7f1ca296-d4b0-e11b-7a70-50379de831c4@solarflare.com> <2061551.U1huFxGPsU@xps> <5aa70bf7-9afd-4c5d-708c-c922288755e8@solarflare.com> In-Reply-To: <5aa70bf7-9afd-4c5d-708c-c922288755e8@solarflare.com> From: Jerin Jacob Date: Fri, 22 Nov 2019 22:32:21 +0900 Message-ID: To: Andrew Rybchenko Cc: Thomas Monjalon , Ferruh Yigit , Pavan Nikhilesh , Neil Horman , John McNamara , Marko Kovacevic , dpdk-dev , Ori Kam , David Marchand , Olivier Matz , "Ananyev, Konstantin" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 3/3] ethdev: improve flow mark Rx offload deprecation notice X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Nov 22, 2019 at 8:54 PM Andrew Rybchenko wrote: > > On 11/22/19 2:15 PM, Thomas Monjalon wrote: > > 22/11/2019 11:12, Andrew Rybchenko: > >> On 11/22/19 1:01 AM, Thomas Monjalon wrote: > >>> 19/11/2019 13:12, Andrew Rybchenko: > >>>> The deprecation notice is required since it adds more requirements > >>>> when RTE flow mark and flag actions may be used and require > >>>> changes in applications. > >>> I am still not sure what is the best solution here. > >>> I continued to think about it in this thread: > >>> http://mails.dpdk.org/archives/dev/2019-November/151960.html > >>> > >>> I think we cannot require any application change until 20.11 > >>> in order to keep API (and behaviour) compatibility. > >> Expected, but still very disappointing. > >> > >> The feature is implemented by Pavan (@ Marvell), supported by me, > >> used by Qi (@ Intel), looks better than alternatives from application > >> developer point of view [1] and finally postponed for 1 year without really > >> strong motivation. > > I see different valuable point of views. This is enough motivation. > > It looks like I miss it in previous discussion, I would be thankful if > you give me links to read or hints how to find. > > > And no, it is not postponed by one year. > > Next release can implement a new API. > > > >> I disagree that it is tightly related to moving > >> mark/flag to > >> dynamic field/flag and absolutely blocked by it. Yes, I know that the are > >> concerns from the very beginning, but the problem is explained [2] and clear > >> and no full-featured alternative solution is suggested. Solution suggested > >> by Ori has many significant drawbacks as explained in [2] and highlighted > >> in further discussion. > > I disagree with working only on mark action while there are a lot > > of other configs which have to be implemented in drivers. > > > > The reality is that some drivers decided to have some "optimizations" > > disabling some features, and you want the application to opt-in > > in order to allow your optimized paths. > > Strictly speaking it is not about driver optimized paths only, but HW > configuration as well which can be done on start-up only (not dynamic) and > could be per-queue in fact. > > > Note that opt-in is different of really enabling an offload. > > For some basic port-level features like RSS hash, > > it is enabled with an offload flag before starting the port, > > acting as an opt-in. > > Could you highlight the difference between opt-in and offload. > What is the key difference which makes one solution better > than another? Why different mechanism is required? > > > Some features have some dedicated API, which may be enabled after > > starting the port, and no way to opt-in (or opt-out) before start. > > It sounds like you have examples in your mind. Please, share. > > > A lot of features are using rte_flow API which is in this situation. > > If we take the opt-in path, let's not do it only for the mark action, > > but let's create a real API for it: > > rte_eth_dev_optin() > > rte_eth_dev_optinall() > > rte_eth_dev_optoutl() > > Introducing new types of controls would make configuration more and > more complex. I think that many different types of control would > over-complicate it. May be it is unavoidable, but it should be clear I agree with Andrew here. Another thing to consider is the behavior of pre rte_eth_dev_opt*() API after reconfigure. Does application needs to call these API again after the reconfigure to bring back the old state prior to reconfiguring? > why the problem cannot be solved using existing types of controls > (e.g. offloads).