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 639D0A0C41; Wed, 6 Oct 2021 19:13:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2B07840696; Wed, 6 Oct 2021 19:13:01 +0200 (CEST) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by mails.dpdk.org (Postfix) with ESMTP id 371644067A for ; Wed, 6 Oct 2021 19:13:00 +0200 (CEST) Received: by mail-il1-f172.google.com with SMTP id r9so3609292ile.5 for ; Wed, 06 Oct 2021 10:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zLLSn51IFUlo5oxxolK3ZIMBvYYzQDYob7XJUxa0IaA=; b=cjuEaj5klhKIaYvfswF1eDxO3FUBlZvrpeq+OrT9FHQk7vZG0QVIerW/xjATPbAP4l Bx9liIDz4EYDU9hEJNfqLwTf6xJx5yDdrvNCdJoEl2VqOqFaCwcmfbQ7C1l4tCCIkyu+ yeQWqFAJ53RPxvV7vp6lW4NN0x+5l62jK8tOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zLLSn51IFUlo5oxxolK3ZIMBvYYzQDYob7XJUxa0IaA=; b=LBeoCVT4gHC4uq1qWE5xRQAwVSgnHaaVg6rRmVR+GVR6TTwshn8knNKXtbujf7OJ0t O66kraPdJzdKJT+xQJYLIsjQ8bUG6EPchH1XAGMfkldsGFmUZ/BDpvtcamXeO7lbILz+ uVa2rp+rHrMF//yJPh/7cMAuM5/q81O1NW+JjyRuhQ6Z9+NbBFzOwlcwXpCVUrpXCk6x 1+7doUvDqZEPU8mBDVFj0haQOSAQQII3lbc5XKli05Bxayu3ck75o5IdjKfkyNHA6E8w wdCentvgUizqZdJKPN//e/y5qCh7Vm9nEV/lMOIoPIYA+z6tUSaaIc9fbjv1MVBQ5LuP 9A5Q== X-Gm-Message-State: AOAM531A5Mw+Do14xOsuxsB9JmQjsXDo1pIm8wt07wi5ZbvyfhUSnwi6 yjFnhzSU3Pz75C9gayvm7usImCGR0ULrCwHrAd53Hw== X-Google-Smtp-Source: ABdhPJzlQOIHgzI3f8OtVhf0fGUGtn32AkJ1cEpre1L2rWDZhcE1kf+kgDu6Tw+hA9NYwTFTv9ec7Gw1wKAYFXTbyXs= X-Received: by 2002:a05:6e02:1985:: with SMTP id g5mr8383413ilf.311.1633540379514; Wed, 06 Oct 2021 10:12:59 -0700 (PDT) MIME-Version: 1.0 References: <20210901085516.3647814-1-dkozlyuk@nvidia.com> <20210901085516.3647814-3-dkozlyuk@nvidia.com> In-Reply-To: <20210901085516.3647814-3-dkozlyuk@nvidia.com> From: Ajit Khaparde Date: Wed, 6 Oct 2021 10:12:43 -0700 Message-ID: To: Dmitry Kozlyuk Cc: dpdk-dev , Matan Azrad , Ori Kam , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000001072e305cdb242be" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions on restart 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 Sender: "dev" --0000000000001072e305cdb242be Content-Type: text/plain; charset="UTF-8" On Wed, Sep 1, 2021 at 1:55 AM Dmitry Kozlyuk wrote: > > rte_flow_action_handle_create() did not mention what happens > with an indirect action when a device is stopped, possibly reconfigured, > and started again. It is natural for some indirect actions to be > persistent, like counters and meters; keeping others just saves > application time and complexity. However, not all PMDs can support it. > It is proposed to add a device capability to indicate if indirect actions > are kept across the above sequence or implicitly destroyed. > > It may happen that in the future a PMD acquires support for a type of > indirect actions that it cannot keep across a restart. It is undesirable > to stop advertising the capability so that applications that don't use > actions of the problematic type can still take advantage of it. > This is why PMDs are allowed to keep only a subset of indirect actions > provided that the vendor mandatorily documents it. Sorry - I am seeing this late. This could become confusing. May be it is better for the PMDs to specify which actions are persistent. How about adding a bit for the possible actions of interest. And then PMDs can set bits for actions which can be persistent across stop, start and reconfigurations? > > If the device is being reconfigured in a way that is incompatible with > an existing indirect action, PMD is required to report an error. > This is mandatory, because flow API does not supply users with > capabilities, so this is the only way for a user to learn that > configuration is invalid. For example, if queue count changes and RSS > indirect action specifies queues that are going away, the user must > update the action before removing the queues or remove the action and > all flow rules that were using it. > > Signed-off-by: Dmitry Kozlyuk > Acked-by: Matan Azrad > Acked-by: Ori Kam > --- > doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++ > lib/ethdev/rte_ethdev.h | 5 +++++ > 2 files changed, 17 insertions(+) > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > index 0a03097a7c..da90b52f48 100644 > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -2794,6 +2794,18 @@ updated depend on the type of the ``action`` and different for every type. > The indirect action specified data (e.g. counter) can be queried by > ``rte_flow_action_handle_query()``. > > +By default indirect actions are destroyed when the device is stopped. > +If the device advertises ``RTE_ETH_DEV_CAPA_FLOW_INDIRECT_ACTION_KEEP``, > +indirect actions persist across the device stop and start with possible > +reconfiguration in between. Some configuration changes may be incompatible > +with existing indirect actions, in this case ``rte_eth_dev_configure()`` and/or > +``rte_eth_rx/tx_queue_setup()`` will fail. At this point PMD developers > +are encouraged to log errors identical to the ones that would be emitted by > +``rte_flow_action_handle_create()`` if the new configuration was active. > +Even if this capability is advertised, there may be kinds of indirect actions > +that the device cannot keep. They are implicitly destroyed at device stop. > +PMD developers must document such kinds of actions if applicable. > + > .. _table_rte_flow_action_handle: > > .. table:: INDIRECT > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h > index 1616bdf2dd..c3be5afcb2 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -1450,6 +1450,11 @@ struct rte_eth_conf { > #define RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP 0x00000002 > /** Device keeps flow rules across restart and reconfiguration. */ > #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP 0x00000004 > +/** > + * Device keeps indirect actions across restart and reconfiguration. > + * For a specific PMD this may not be applicable to certain action types. > + */ > +#define RTE_ETH_DEV_CAPA_FLOW_INDIRECT_ACTION_KEEP 0x00000008 > /**@}*/ > > /* > -- > 2.25.1 > --0000000000001072e305cdb242be--