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 CEFD6A0350; Sun, 28 Jun 2020 15:42:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B1EAB1C23E; Sun, 28 Jun 2020 15:42:38 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id EA7B31C031 for ; Sun, 28 Jun 2020 15:42:36 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id c16so14434026ioi.9 for ; Sun, 28 Jun 2020 06:42:36 -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=VNk3npRkrHID9HSS84wlH6YcSyrh162KeolHtf4jYlc=; b=MrC6G2TK09SBGqks2Fw2Pq+R0090OrgEoBm4PQyCXhckNXPhRyNqdgcNe5Uo38BG7r p9Yr03A3kvA4vsbCVxKAtb7veA2X8TXNAVO8WPB4UGKQ70d3M/Q04d1LOuiK5zqw9Yit 5psH11POt/gZtClGvcHmeGKhi8ElYFF4Aiox5VYUWVqlN8z+XH/MwP3yjTZM+bYGbSqY k8sFnr08PObrmDGcqTdTNtkhk1pxEs1AYgV+EDeeS7qHMP1bUUcTfEN2vtcqouZFk1JV wIWeClp+KGSlxQl3heGmMzl2Ragwo/YSyw6UGFINDUNYcGhoRmLNR18v8Khj3uKyKYYd 1X3g== 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=VNk3npRkrHID9HSS84wlH6YcSyrh162KeolHtf4jYlc=; b=l5Ci+s+44iXjwNX0/qUqyfRHXJXH5DxIvkU7mKxoVC+mfO9rmXrY0IeB7eE5lKDkuJ yZGyYt/6hD/edVdsRKGuDswhHNcH4Kkaj7+yeGYotTgW0yhWuLNsBP8zNT9SkUzk7zH+ MuSAbUH5qHffdj6QtQIFDJrr2XCLGs1xQHGi9SXPDGPflVtJ+jd+1GI4wt24YY+R0okA vNkr66n/5IOx/xfyTaPWWVOr1hMLMJf5trdv0m7/Hv1n+EZ4G7eBIgG3sgOotTOFPPl3 gw/njq52JFGyQ58T8S2ZlSUZzV/LkRwsbU4eSHp11Rcp+g1u5Gon1U4cNLSFft61dQgD bKfQ== X-Gm-Message-State: AOAM533HmkmJ0kh3bvQHAyOIatHAfa8H1BZZiEhuSE+FNHuZK/P9+hvR Y4gSiN0VpA8kj0dK5BAJHvfvgb4jAP3GyUKBGO4= X-Google-Smtp-Source: ABdhPJz35+dj0q2yKD8kWj69XTDMbeQ7fIodoEtA32psyCkwnF2B1AHh254KwYptImlMHcDb6b+dPCP/krEnlf2viUA= X-Received: by 2002:a02:3501:: with SMTP id k1mr12869940jaa.133.1593351756217; Sun, 28 Jun 2020 06:42:36 -0700 (PDT) MIME-Version: 1.0 References: <20200620133231.12355-1-andrey.vesnovaty@gmail.com> In-Reply-To: From: Jerin Jacob Date: Sun, 28 Jun 2020 19:12:20 +0530 Message-ID: To: Andrey Vesnovaty Cc: Thomas Monjalon , dpdk-dev Content-Type: text/plain; charset="UTF-8" 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" On Sun, Jun 28, 2020 at 2:14 PM Andrey Vesnovaty wrote: > > 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)? Yes. > How should it be implemented by PMD? See below, > Is it about shared action and if "yes" why there is 'flow' argument? flow holds the "pattern" and "action" data as PMD specific handle. So PMD, implementation can just change that action if it gets the PMD specific handle. >> >> >> 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"? Yes. When it 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"? Yes.