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 512FCA0350; Mon, 29 Jun 2020 12:22:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5A1841B91B; Mon, 29 Jun 2020 12:22:25 +0200 (CEST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by dpdk.org (Postfix) with ESMTP id 159221B5E1 for ; Mon, 29 Jun 2020 12:22:23 +0200 (CEST) Received: by mail-lf1-f46.google.com with SMTP id u25so8781895lfm.1 for ; Mon, 29 Jun 2020 03:22: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=sGnG10ax9kV4L3OnA2DDzQr+TZXsv6SyJ/OATqhPXn4=; b=Iv+nnvDRV++o1S8NaYplbmkmAWGjRp8hOV4LNeX65A0CdU3VQ/U/Yp0uAELHGrXfxJ 1qu+U0A7LWt6lGU2EGiEVkuuSnNa3UTD5hrixv5VHxRBVGS7GJzDuyhutJ6gUM/ML13Y SJY4Q5TRLeWh6F2mUWcWbkKJNHAH7M7Aqao2/WwiZ+6RGUN8S1eA52J1P30xpvgofw0O 5rl2C6q95iE+WgnFaISNIAyxSf2vTYgwYxp8pjh5KXaqnOeMfFoYA5T4ETIynhe/P6a1 fEAp8aAu0lFc408Nr7aHhMffaQRa0Y4gPEH6mtNzHqfXPc/c8rJOD9RR49n0FRfL/aep +tIw== 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=sGnG10ax9kV4L3OnA2DDzQr+TZXsv6SyJ/OATqhPXn4=; b=nOMmpF/ZDLdQmEMWn+gAaEDbAG+Hkx3h6Q0nTICOVEFR+d7auqOqnTmRipwKVclJS3 NC3ETUp10VYB/GipLsCsNj8TxVmV1IW++tAVTJmCXiPcAayKD9CZqIb+a5mqJ3rF/Zeh lHRl2vgLzYgQwWlY01NjoHlZpZS3Qo9pqyyaBun+V8asK/haX+lgtnKBvnuOGMv30o8d 8vQa3LZM+lHqgjEr3Ca3XbzJ9MdFubA6zyk6fCc8K6Lhh1QyHar6c214wRJ/4FzoiZjB MpTyrCdJfSA9I4wgtxrLZ22nymw3YlDi6GzYz19iaQlpI7iNa8Q6HvSIM5cyEWPAMi7m 2mfA== X-Gm-Message-State: AOAM533wQp/KSGJ8p9PoPqO3c+d8/YTzGu9trrfIsV7SJW8gruDIvE/B FE4ilg81rW0EbOtjBdLY3ZXoqk8WyuY6ruWhpj8= X-Google-Smtp-Source: ABdhPJwV5gmpHtQFdQLn/RmFRzSCnAjYxQOj08c7vV4cyL074BUYfTQkieKWSBmVDE5EXNvoaO73im0KbV/hyad0JHw= X-Received: by 2002:a19:8806:: with SMTP id k6mr8713459lfd.189.1593426142423; Mon, 29 Jun 2020 03:22:22 -0700 (PDT) MIME-Version: 1.0 References: <20200620133231.12355-1-andrey.vesnovaty@gmail.com> In-Reply-To: From: Andrey Vesnovaty Date: Mon, 29 Jun 2020 13:22:10 +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" On Sun, Jun 28, 2020 at 4:42 PM Jerin Jacob wrote: > 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. Jerin, few clarifications regarding generic implementation of shared action: Based on this conversation I'm assuming that generic implementation supposed to be something like: For each flow using some shared action: call ops-> action_update() If the assumption above correct: 1. taking into account that shared_action_update() is atomic, how can this deal with partial success: some flows may fail validation - should it: 1.1.lock all flows 1.2.validate all flows 1.3.update all flows 1.4. unlock 2. action_update callback is PMD specific & if it's unsupported there is no support for shared action any way Please address the issues above > > >> > >> 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. > Common 'shared session' management code: - can be reduced to atomic usage counter - maintaining list of flow using shared action expected to impact performance & not necessary for all PMD specific implementations Access to other shared resources hard to generalize because: - for some PMDs mutual exclusion is HW feature & no need to protect it in SW - for others there may be multiple resources & access to each one protected by different mechanism An observation related to action_update callback: If replaced (updated) action was shared then the flow won't be influenced any more by updates or removed shared action.