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 8BB70A00C5; Thu, 4 Jun 2020 13:25:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2A8611D5DA; Thu, 4 Jun 2020 13:25:25 +0200 (CEST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by dpdk.org (Postfix) with ESMTP id 5FBA31BED5 for ; Thu, 4 Jun 2020 13:25:22 +0200 (CEST) Received: by mail-lj1-f175.google.com with SMTP id a9so3236656ljn.6 for ; Thu, 04 Jun 2020 04:25:22 -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=DsIXvQlOum+QOY0ZWRWs3UZv2Ybta/rMME0MfaL/nxs=; b=WdRtfZk/Z2eAthQAFi/LcdPsBtAm6HU3Mus4q7GnvmoFhuWmAyM8sWMXtS+X92h6fV 06q6c8OH7hGXW86U80afc2EVZyBNwL1tp7JyrBtFxMZwQf7YgO2vhNWbqT5EQjRHmJDa cgnogU1Dy5bWsz8C5GdgMpnUzGihbTVXdDlRC4U5DtL+VOLJThmGMHmys/kj08J7yUTj 1KT/2xYLF/teBmx/v2p5i3UFWcLF1FdW9mx4xcLa4R8ZnOvhz5JO7hJqe8Eow8Ay1SIK DNL1fBbwyPMlvaz2cPLkq0bmHlDPBL8Hne2dERXb0d5CbC/vxLbZaaGbJnKboMNXXOsS FGJA== 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=DsIXvQlOum+QOY0ZWRWs3UZv2Ybta/rMME0MfaL/nxs=; b=h786cK6X+XrITIChonpgM9kQUN5exDSwP3yadorcneWoOQXIFocrLzJA1ERB5EpsKV /LVrmmfBgJrmQfXXCP7CuC8/inUsfV0dWYI2Gy8afyJcKGd11YrWH9yBtMQxSLhjTANu VAtNlYWf+sQ634WiRuXMWpvnUFE/SdZwriMxL3y+f4iZ5aB5mrlj7ZgLXzuX20Y4aGlk ndNqCl9+BmykpOK339LV7BmSlmtNRhhUxSPzd/9Dwi7dgd31dK40nDd3lK31g0IUcmtV zxQTIUi2piZ6QArS1f1I/ozNhMtSw6gkZktU7wRIoTbHQscIWMKSJaOVOv18YxGj+O6M fP9A== X-Gm-Message-State: AOAM533m9sNTjs6tTMjDYP7dbOT6QRs6qqFF8yowUTvugZ64+WF0Z0ai 7W2m/VTNIWGRhH/5hCjagmC3BQvfCukiBtJBYvU= X-Google-Smtp-Source: ABdhPJyl/FcvVv48KxDORlyQBS9WRy+J2nOO0J2uZYjytrxcoNg37XwS2gRK++81tUhdzY1raB/JMa+o29IgS4bTUQk= X-Received: by 2002:a2e:5c2:: with SMTP id 185mr1835874ljf.260.1591269922243; Thu, 04 Jun 2020 04:25:22 -0700 (PDT) MIME-Version: 1.0 References: <20200520091801.30163-1-andrey.vesnovaty@gmail.com> In-Reply-To: From: Andrey Vesnovaty Date: Thu, 4 Jun 2020 14:25:11 +0300 Message-ID: To: Jerin Jacob Cc: Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Ori Kam , dpdk-dev Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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, Jun 3, 2020 at 1:53 PM Jerin Jacob wrote: > 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? > > The benefit (or goal of the proposed API extension) is to modify the behaviour of multiple flows by single API call. > Would the following additional API suffice the motivation? > > rte_flow_modify_action(struct rte_flow * flow, const struct > rte_flow_action actions[]) > This API limits the scope to single flow which isn't the goal for the proposed change.