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 749F9A0350; Sun, 28 Jun 2020 10:44:33 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 566731C012; Sun, 28 Jun 2020 10:44:32 +0200 (CEST) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by dpdk.org (Postfix) with ESMTP id 97E891BFD1 for ; Sun, 28 Jun 2020 10:44:30 +0200 (CEST) Received: by mail-lj1-f172.google.com with SMTP id e4so14609298ljn.4 for ; Sun, 28 Jun 2020 01:44:30 -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=rX6QPhPg4DDP3uEXpb2H74y6JdWs6MG2oz6sF/j3N90=; b=F7Xax799HCmjTDKL6linZqTeaDVkeECzUBiVwVGBI4swVKtXWZfgS0F5ynn1FBwraN 9bhstJTuvh1QEYwj1iswmrVlsrc0XFks4XkrUAYLc3ubcI7l/V3UAwIgufUeCdxWD4fg lCZbXktxCuSdP2LzRN7v2DGPJU7uRf+lMDwO4AjJ2t0uE8VXtX1Z44lQmDN5vf7HIVbE APkCJUksF95aEd3AcsDgx0TGj/lBjq4MFk5xQZfmctOGGyVcMXY3OsvbDstdK+WL7ZPL kLEsu8jKGpnIpzTddukUy07oOumncBCy9zi7M2PylEh5rcr2h83OiNkIw7nUJ9sIsGSf t8Kg== 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=rX6QPhPg4DDP3uEXpb2H74y6JdWs6MG2oz6sF/j3N90=; b=muhCEJNzijN0jFgJ/iuOrIoSSb9uSaMPj9F/4CgH3T7B8r2oV0WnA72G3pNeWKM0Ob uFjzSUk3I917qMuKAatWAruLbu6OFfa4tnpQv1tEa6fBIGwWzua+BhcwGBQkxKy0DjBq yjcuGANIEYSQ7JH6OnXFMKTJkDwcuDAmbfIInlPYyPbHeiQPKehxXbT0F3msLlZaP6vp jQbLg79pwas+Yebl6JuBACPEm1oS+jODjsZjnu64aaXZ1LKNhCfBhq2Rkr3ulkU+eSLK wMwgzus5XevJpeBROum+I9xC/JXNabnFYLIdvaQZc9t46Vvy0auZjd6WtyoabARA3+in f0iQ== X-Gm-Message-State: AOAM532faSBl+plBa80omoFBySiAmuU2yKHuME/Noiy21ZJtsvNMi+eQ 55+G0nrSZe1zl4Hy1RbRbSldLy6s/j7feg+H90A= X-Google-Smtp-Source: ABdhPJx28SJr75ooCfmgmpgwfCb4beXSmWleYTqQka4ZCjG8k7AfAEFkrtUUP3/OPgEMMZfOCv120xi/uaq8G5FdARY= X-Received: by 2002:a2e:9ac4:: with SMTP id p4mr1941746ljj.143.1593333870173; Sun, 28 Jun 2020 01:44:30 -0700 (PDT) MIME-Version: 1.0 References: <20200620133231.12355-1-andrey.vesnovaty@gmail.com> In-Reply-To: From: Andrey Vesnovaty Date: Sun, 28 Jun 2020 11:44:19 +0300 Message-ID: To: Jerin Jacob Cc: Thomas Monjalon , dpdk-dev Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC v2 0/1] 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" Hi On Fri, Jun 26, 2020 at 2:44 PM Jerin Jacob wrote: > On Sat, Jun 20, 2020 at 7:02 PM Andrey Vesnovaty > wrote: > > > > Hi, and thanks a lot for your RFC v1 comments. > > > > RFC v2 emphasize the intent for sharing the flow action: > > * The term 'action context' was unclear and replaced with > > 'shared action'. > > * RFC v2 subject became 'add flow shared action API'. > > * all proposed APIs renamed according the above. > > > > The new shared action is an independent entity decoupled from any flow > > while any flow can reuse such an action. Please go over the RFC > > description, it was almost entirely rewritten. > > > > @Jerin Jacob: > > Thanks again for your comments, it made me admit that v1 description was > > incomplete & unclear. I hope v2 will be better at least in terms of > > clarity. > > The public API and its usage is very clear. Thanks for this RFC. My pleasure. > > I think, RFC v2 still not addressing the concern raised in the > http://mails.dpdk.org/archives/dev/2020-June/169296.html. > > Since MLX hardware has an HW based shared object it is fine to have > public API based on that level of abstraction. > But at the PMD driver level we need to choose the correct abstraction > to support all PMD and support shared object scheme if possible. > > I purpose to introduce something below or similar > int (*action_update) > (struct rte_eth_dev *, > struct rte_flow *flow, > const struct rte_flow_action [], > struct rte_flow_error *); > Where this callback suppose to belong (struct rte_flow_ops)? How should it be implemented by PMD? Is it about shared action and if "yes" why there is 'flow' argument? > > in addition to: shared_action_create, shared_action_destroy, > shared_action_update, shared_action_query > > Have generic implementation of above, if action_update callback is not > NULL. "is not NULL" -> "is NULL"? > So that, it can work all PMDs and to > avoid the duplication of "complex" shared session management code. > Do you mean shared action in use by multiple flows by "shared session"?