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 18F25A0512; Wed, 3 Jun 2020 12:53:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6838B1D15F; Wed, 3 Jun 2020 12:53:22 +0200 (CEST) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) by dpdk.org (Postfix) with ESMTP id CD6CA1D152 for ; Wed, 3 Jun 2020 12:53:20 +0200 (CEST) Received: by mail-il1-f171.google.com with SMTP id a13so2022878ilh.3 for ; Wed, 03 Jun 2020 03:53:20 -0700 (PDT) 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=f9hCXcswbSj2gSQhyj75O5b0/KhbZ6J8FOXh/LOwfvk=; b=fTBizGwxeUXhbfZjChdtVihpcVuP0GOIHAIYHM26cMCqE5xBQB7jNPE6cTBot1lxeC 6fVg7dSxYonnIY1GINd3byDWbaEEGh+wFlkRQfInZLSu0c8UKfa/zpYr6Y2lLSIbVkfu rxvREdfpUjS+ukkW9dzQRQ88D1+PnWsfa445kCIeao55CoQKqV3cFyxLuF9k9klTozu0 0NE9m98191MKXpC3vZexP/7kh3HntvP5zVttbi8T6G4v+JJQs1wiI0al4LzncQIhOn89 aqPMUzp+3QCiyIaLJAlgAYL5+fwoPjOQCMvzhHtSBlUPjAANLzDBhhk8liS/aTMGzWtx lIpg== 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=f9hCXcswbSj2gSQhyj75O5b0/KhbZ6J8FOXh/LOwfvk=; b=LewqziVLQWRDjl9dmUeeRfc9aN+P9EKuQtNThHNNyXa9prveRMzmtE78Aj/Wf5jAl3 WqzNb0jRVgYojeW9VfNt6x1kOR/5+WjrZZMZS85/0tNkZCOQtgpy95gDcReiwAOI6xsw xicGKk4IO7vIwGTeSBpMw5FSP5dFrjlPeRjYnGEmHCruWzoWF8OxKnub7JiOhuBu9QPe Nfd2DJwCw+k7ySuU0KBJId6R/zS2O+ldQyI2BVC82+hwulx/KGx4j0DR513cVjkM8rYD H7FqXlLrAC5Fx9zwN4ePFYnVSnKFykQ6MeeQ+HCwoDdaQVo3yvkxg6HftjZo3h7OWCni UfFg== X-Gm-Message-State: AOAM530kfem5s+kug8VPT0izblNKJQdc5pHPL6pxk17B9C748i1VmeMN gRwk1tzkrO9jMA0FreB+h/Df18s4qfLiT/+iLCo= X-Google-Smtp-Source: ABdhPJy8qHH4BvaCjq2PJdOBnzI3yHjFyhGsEA8N+AyVcIohyqrcSLgPwJZ/bR7tEPYQmUT9cU6OECWSojbfcXC4/Mw= X-Received: by 2002:a05:6e02:13f4:: with SMTP id w20mr3249476ilj.294.1591181600045; Wed, 03 Jun 2020 03:53:20 -0700 (PDT) MIME-Version: 1.0 References: <20200520091801.30163-1-andrey.vesnovaty@gmail.com> In-Reply-To: <20200520091801.30163-1-andrey.vesnovaty@gmail.com> From: Jerin Jacob Date: Wed, 3 Jun 2020 16:23:03 +0530 Message-ID: To: Andrey Vesnovaty Cc: Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Ori Kam , dpdk-dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC] add flow action context API 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 Wed, May 20, 2020 at 2:48 PM Andrey Vesnovaty wrote: > > This commit introduces extension of DPDK flow action API enabling > modification of single rte_flow_action. > > Motivation and example > === > Adding or removing one or more queues to RSS actions cloned in multiple > flow rules imposes per rule toll for current DPDK flow API; the scenario > requires for each flow sharing cloned RSS action: > - call `rte_flow_destroy()` > - call `rte_flow_create()` with modified RSS action > > In order to prevent the overhead of multiple RSS flow rules reconfiguration > API for in-place flow action modification introduced in this commit. > > Change description > === > Provide an API to create single rte_flow_action context to point/reference > rte_flow_action object contents from multiple rte_flow_rule objects. > Actually the introduced API makes action object shared and modification > of such an action effects all the rules referencing the action via context > (see struct rte_flow_action_ctx). > > Action context lifetime > --- > Once action context created (see rte_flow_action_ctx_create()) it can be > safely reused for: > - new flow rule creation > - action configuration/state modification > (see rte_flow_action_ctx_modify()) > - action state query (see rte_flow_action_ctx_query()) > Once rte_flow_action_ctx_destroy() called the destroyed action context > should not be used i.e. result of the usage undefined. Motivation makes sense to me. It will be an improvement. But creating shared objects adds additional complexity to "PMD and application" as it needs to manage the state. Since rte_flow_action already expressed in vendor natural format, What will be the benefit of a shared context? Would the following additional API suffice the motivation? rte_flow_modify_action(struct rte_flow * flow, const struct rte_flow_action actions[])