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 73973A0C3F; Thu, 15 Apr 2021 19:59:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 459301623EC; Thu, 15 Apr 2021 19:59:52 +0200 (CEST) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by mails.dpdk.org (Postfix) with ESMTP id 75A041623DC for ; Thu, 15 Apr 2021 19:59:51 +0200 (CEST) Received: by mail-qt1-f169.google.com with SMTP id d6so572179qtx.13 for ; Thu, 15 Apr 2021 10:59:51 -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=2syrbsSX/8Ykf8M8wsQZSneZNHHQSqd2sI/Q/uVdcKw=; b=cuPQDcXprlRSJLuRGzfwClKGpBTr77bNybY1zD6O0K4DSBuB4UPT6iuqA7VHCGplXd UGZEm+/WsrRHBmhHq0z0bWSWleTCvVjdssf5sLI/TvOd4bdodyLyHnDZRx3RMQvfoR1T TQeEjsOaf4I/tCTundlOdhwVSZqFQIn5gmRGM= 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=2syrbsSX/8Ykf8M8wsQZSneZNHHQSqd2sI/Q/uVdcKw=; b=itVtGW2kh7bcNTZq9RSnsHTnTK7bwo6wo0LFVO0jSlgpjhZI3xPgIPvkrU77mrwcwd UNblyoO+E+6burTRL8MH6bWGNAvULqZl0OrOx6riJsCPu27T0JXnyN9XmKcfJhtZWC7X VOz7834V5z3lR4O6F2u/i/V0XYoILTrLELtmLJgONf/dfvbwuPBY193No8IKeVZuwyVi nqG4QGDBC9GLaP7CjNki2CZGfclQ/drg5OjnpY4Dhbpyx8oOJgaFs582MCZ3Uaq9a9is +PJVEDcz843xxd+KaWpM65QZUwGT/KQFq6DiZrzE65LcoAOfN0cKdL29+WHJqK0pNDQQ fRBg== X-Gm-Message-State: AOAM5319b9Gy6ZKLWyq9aJ+QqMpXln52uRMWiYLoYPseiqtaISIo5XfH yvmS3PCusMiNGqkT/VdC8+7nNNz50k6E12NSeRnzig== X-Google-Smtp-Source: ABdhPJw3angWsBKY7wHNQvSpZ10cmPvOvjwHxYhLLe2vk0FZWvN3P1Jj6Cg4AnJl3PxxGCOMXYbSkgcXsXeY6vQZoi4= X-Received: by 2002:ac8:6f48:: with SMTP id n8mr4271146qtv.22.1618509590554; Thu, 15 Apr 2021 10:59:50 -0700 (PDT) MIME-Version: 1.0 References: <1617940481-125528-1-git-send-email-bingz@nvidia.com> <1618501912-92525-1-git-send-email-bingz@nvidia.com> <1618501912-92525-2-git-send-email-bingz@nvidia.com> In-Reply-To: <1618501912-92525-2-git-send-email-bingz@nvidia.com> From: Ajit Khaparde Date: Thu, 15 Apr 2021 10:59:34 -0700 Message-ID: To: Bing Zhao Cc: Ori Kam , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Matan Azrad , Slava Ovsiienko , dpdk-dev , Gregory Etelson , Andrey Vesnovaty Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003d962705c006a182" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH v3 1/1] ethdev: introduce indirect action APIs 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" --0000000000003d962705c006a182 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 15, 2021 at 8:52 AM Bing Zhao wrote: > > Right now, rte_flow_shared_action_* APIs are used for some shared > actions, like RSS, count. The shared action should be created before > using it inside a flow. These shared actions sometimes are not > really shared but just some indirect actions decoupled from a flow. > > The new functions rte_flow_action_handle_* are added to replace > the current shared functions rte_flow_shared_action_*. > > There are two types of flow actions: > 1. the direct (normal) actions that could be created and stored > within a flow rule. Such action is tied to its flow rule and > cannot be reused. > 2. the indirect action, in the past, named shared_action. It is > created from a direct actioni, like count or rss, and then used > in the flow rules with an object handle. The PMD will take care > of the retrieve from indirect action to the direct action > when it is referenced. > > The indirect action is accessed (update / query) w/o any flow rule, > just via the action object handle. For example, when querying or > resetting a counter, it could be done out of any flow using this > counter, but only the handle of the counter action object is > required. > The indirect action object could be shared by different flows or > used by a single flow, depending on the direct action type and > the real-life requirements. > The handle of an indirect action object is opaque and defined in > each driver and possibly different per direct action type. > > The old name "shared" is improper in a sense and should be replaced. > > Since the APIs are changed from "rte_flow_shared_action*" to the new > "rte_flow_action_handle*", the testpmd application code and command > line interfaces also need to be updated to do the adaption. > The testpmd application user guide is also updated. All the "shared > action" related parts are replaced with "indirect action" to have a > correct explanation. > > The parameter of "update" interface is also changed. A general > pointer will replace the rte_flow_action struct pointer due to the > facts: > 1. Some action may not support fields updating. In the example of a > counter, the only "update" supported should be the reset. So > passing a rte_flow_action struct pointer is meaningless and > there is even no such corresponding action struct. What's more, > if more than one operations should be supported, for some other > action, such pointer parameter may not meet the need. > 2. Some action may need conditional or partial update, the current > parameter will not provide the ability to indicate which part(s) > to update. > For different types of indirect action objects, the pointer could > either be the same of rte_flow_action* struct - in order not to > break the current driver implementation, or some wrapper > structures with bits as masks to indicate which part to be > updated, depending on real needs of the corresponding direct > action. For different direct actions, the structures of indirect > action objects updating will be different. > > All the underlayer PMD callbacks will be moved to these new APIs. > > The RTE_FLOW_ACTION_TYPE_SHARED is kept for now in order not to > break the ABI. All the implementations are changed by using > RTE_FLOW_ACTION_TYPE_INDIRECT. When I read this somehow indirect did not feel right. But I don't have a strong suggestion either. Since it is a context of action or actions maybe we use action_context? > > Since the APIs are changed from "rte_flow_shared_action*" to the new > "rte_flow_action_handle*" and the "update" interface's 3rd input > parameter is changed to generic pointer, the mlx5 PMD that uses these > APIs needs to do the adaption to the new APIs as well. > > Signed-off-by: Bing Zhao > Acked-by: Andrey Vesnovaty --0000000000003d962705c006a182--