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 91812A00C5; Mon, 6 Jul 2020 11:00:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F37A21DA63; Mon, 6 Jul 2020 11:00:23 +0200 (CEST) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 178A81DA11 for ; Mon, 6 Jul 2020 11:00:23 +0200 (CEST) Received: by mail-io1-f67.google.com with SMTP id q74so14939956iod.1 for ; Mon, 06 Jul 2020 02:00:23 -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=r9PnsE0TXcM/Gr8CfUxvxmSSoX+ykthZ6vEmRkrau5k=; b=GOUqJquo14Ms3k0r9o2Fcuvq5RoZ4HpxhWN55XmSPM+IBmJL+J8Di0FXRLecg4hVOy EYv08vbJtHdRWvqoXuPM8ujVhTb6aPINFrTc4sVinUnw6A/75OXfYaYEDXSmTa8itBEZ Y66R/lv+BLYPBCnAX0Il07fPxTpgDwIpQtjhBCNMRwoTVqJfjj6fqpibeZyE8wthpJKc WK4x993f2E7UNmlG9UlmGSt/r6IltAZ8i/MJnfrZZL04PySyImfQ9KXDTFPBiERyZYdG kUPBHYUc1BFPJg4JrxP4+QZM7Br5BOvgjWVFTc2BFKxm9HdsRiSMI5RuQlwUEH3l5Z+F N35w== 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=r9PnsE0TXcM/Gr8CfUxvxmSSoX+ykthZ6vEmRkrau5k=; b=sv6Iip8bQw/3mTRrzGo0sCRiWMEjFAzL/ApJ3k04DQ4oRLkE5GzBbBhBkKORw6MFwD NlANvJ5OtZhJJX3ePDmmC1PP9vj8dik0tdy6x7eBQWlv3bjbbmH0YUOSeD2+A/FXWM41 4mIJjK1hv4uzwViaJ0HTIAz9Nl2xw7PMb/tbV0drG8+/bkBgKoUPBdOqo1XTNaXTs+n1 wVtESxDnjlAm/gsTxwsMN12T8KjFs9rZMwlOsyQJ7Q0xFWkrCRaI2xnN8NUFDV0MmoRz hsgWk6fbMcpL/leGCigqbN2xpwLbnL0etgbWqA9lb1TNozZCF8CWOYttbTuAe63/GAKh iDkg== X-Gm-Message-State: AOAM531FRSjztkwHewGdww9bD6Fgu2/4E63qUQ2GJEVy8PfU0ctRPBEm qJOgqyJAV2vt3tQXoXU0rPvEb2qj3fs5gU9L/ic= X-Google-Smtp-Source: ABdhPJw+e0Lsrvezot9Sd/FVB26KiAiicjAADb36YHInu8ImzvQW0nP+mf5gTt5sUQ0hXeESc7EMkCIjiV7gz40HaeU= X-Received: by 2002:a05:6602:21c7:: with SMTP id c7mr24500865ioc.1.1594026022232; Mon, 06 Jul 2020 02:00:22 -0700 (PDT) MIME-Version: 1.0 References: <20200702120511.16315-1-andreyv@mellanox.com> In-Reply-To: From: Jerin Jacob Date: Mon, 6 Jul 2020 14:30:06 +0530 Message-ID: To: Ori Kam Cc: Andrey Vesnovaty , Andrey Vesnovaty , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , dpdk-dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] add flow shared action 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 Sun, Jul 5, 2020 at 3:56 PM Ori Kam wrote: > > Hi Jerin, > PSB, > > Thanks, > Ori > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Saturday, July 4, 2020 3:33 PM > > dpdk-dev > > Subject: Re: [dpdk-dev] [PATCH] add flow shared action API > > > > On Sat, Jul 4, 2020 at 3:40 PM Andrey Vesnovaty > > wrote: > > > > > > > > > Thanks, > > > > > > Andrey Vesnovaty > > > (+972)526775512 | Skype: andrey775512 > > > > > > [..Nip ..] > > > > I need to mention the locking issue once again. > > > If there is a need to maintain "shared session" in the generic rte_flow layer > > all > > > calls to flow_create() with shared action & all delete need to take > > sharedsession > > > management locks at least for verification. Lock partitioning is also bit > > problematic > > > since one flow may have more than one shared action. > > > > Then, I think better approach would be to introduce > > rte_flow_action_update() public > > API which can either take "const struct rte_flow_action []" OR shared > > context ID, to cater to > > both cases or something on similar lines. This would allow HW's > > without have the shared context ID > > to use the action update. > > Can you please explain your idea? I see two types of HW schemes supporting action updates without going through call `rte_flow_destroy()` and call `rte_flow_create()` - The shared HW action context feature - The HW has "pattern" and "action" mapped to different HW objects and action can be updated any time. Other than above-mentioned RSS use case, another use case would be to a) create rte_flow and set the action as DROP (Kind of reserving the HW object) b) Update the action only when the rest of the requirements ready. Any API schematic that supports both notions of HW is fine with me. > As I can see if we use the flow_action array it may result in bugs. > For example, the application created two flows with the same RSS (not using the context) > Then he wants to change one flow to use different RSS, but the result will that both flows > will be changed. Sorry. I don't quite follow this. > Also this will enforce the PMD to keep track on all flows which will have memory penalty for > some PMDs.