From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 63FEBA04A8; Mon, 24 Jan 2022 15:37:28 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EB6354114A; Mon, 24 Jan 2022 15:37:27 +0100 (CET) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) by mails.dpdk.org (Postfix) with ESMTP id 0285D40040 for ; Mon, 24 Jan 2022 15:37:26 +0100 (CET) Received: by mail-il1-f182.google.com with SMTP id r15so14012616ilj.7 for ; Mon, 24 Jan 2022 06:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jddzy9KhLD/I7gXiNh3Pmn8TpUwJvGLLvRPN9X6Gl/A=; b=McDEyFkl0RMOtNKjNteDDbKvcIvYXzsBUIDkad8BdC+Eae/To+YcMncuQMB5yKcw50 e0D7AgtKX6TZjS2Yt/FlhP/oFN3ZqUz4XmiPZ2Wvi620OQqYOlYxs/c9/Co6g5nGeaOn iNhsfOjHEjQ1iYSOYTcB5M66qAL7EWPjLY7XVfxd+raDEl7QMFJ+ED8/QhirwxteBu68 ivf6Qh6Ww+BYq21ngsrS0Dc79TR6VFzjQon4tLdzBrjzg8nIcIkBTovqA65PbgV1rLjp VfDV2qA5OeliJRZXbMQ6FnI8w8ShDjLiUhDbxDzDQjnJSDBURvE34FAsyaaWtGDBNPf/ O5cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jddzy9KhLD/I7gXiNh3Pmn8TpUwJvGLLvRPN9X6Gl/A=; b=Ja6e1KIjRtEgRAL5LGcktIVEpexuspQZwJjts5CgyYUDuYmhsrpGxY54ia3A4aEuq3 LCqufKchMTBBibg0Qq6fJM4kbRt70tiY7BnPaXu1zQKPbgF9jzp7td/MMjB+xsPOBmNn Z8Ov2OlBej1C7Mo/SIG2P3sWM4h7WsWzSGEOPXgLlxDHji9JkGg2TJSghtWWlPy9YhME 8vxHZ0nret4RmcuOcu7CBxl1Ea+fBzzW06QoQFnzveqMg2inP2I97zIfC1X9eXtjnfeD ueH0s0dL3CExzrPZjrLEwWADjcazMg9RTVJC9r1lAFGMf65cX4BFpJMsaiWW2wti02Ar e/lw== X-Gm-Message-State: AOAM533niFbsnlwUrQbasmgjd4bJKD0rG6UpoIVrjzZUr+xAtpOCh26X 5MM3Yops+Afkld4LB7V2bYEduoQD6p7p1n+c0ME= X-Google-Smtp-Source: ABdhPJzl6vB0l6KDPsz7bllH0miL1YF5hAvdjlLPgmj01grID7YiKcYEIlLoY3bzEODOhfKPLWCIdNe/XPJxZMj1+Jk= X-Received: by 2002:a05:6e02:5d2:: with SMTP id l18mr9036370ils.294.1643035045230; Mon, 24 Jan 2022 06:37:25 -0800 (PST) MIME-Version: 1.0 References: <20211006044835.3936226-1-akozyrev@nvidia.com> <20220118153027.3947448-1-akozyrev@nvidia.com> <20220118153027.3947448-2-akozyrev@nvidia.com> In-Reply-To: <20220118153027.3947448-2-akozyrev@nvidia.com> From: Jerin Jacob Date: Mon, 24 Jan 2022 20:06:58 +0530 Message-ID: Subject: Re: [PATCH v2 01/10] ethdev: introduce flow pre-configuration hints To: Alexander Kozyrev Cc: dpdk-dev , Ori Kam , Thomas Monjalon , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , mohammad.abdul.awal@intel.com, Qi Zhang , Jerin Jacob , Ajit Khaparde Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Jan 18, 2022 at 9:01 PM Alexander Kozyrev wrote: > > The flow rules creation/destruction at a large scale incurs a performance > penalty and may negatively impact the packet processing when used > as part of the datapath logic. This is mainly because software/hardware > resources are allocated and prepared during the flow rule creation. > > In order to optimize the insertion rate, PMD may use some hints provided > by the application at the initialization phase. The rte_flow_configure() > function allows to pre-allocate all the needed resources beforehand. > These resources can be used at a later stage without costly allocations. > Every PMD may use only the subset of hints and ignore unused ones or > fail in case the requested configuration is not supported. > > Signed-off-by: Alexander Kozyrev > --- > > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Flow engine port configuration attributes. > + */ > +__extension__ Is this __extension__ required ? > +struct rte_flow_port_attr { > + /** > + * Version of the struct layout, should be 0. > + */ > + uint32_t version; Why version number? Across DPDK, we are using dynamic function versioning, I think, that would be sufficient for ABI versioning > + /** > + * Number of counter actions pre-configured. > + * If set to 0, PMD will allocate counters dynamically. > + * @see RTE_FLOW_ACTION_TYPE_COUNT > + */ > + uint32_t nb_counters; > + /** > + * Number of aging actions pre-configured. > + * If set to 0, PMD will allocate aging dynamically. > + * @see RTE_FLOW_ACTION_TYPE_AGE > + */ > + uint32_t nb_aging; > + /** > + * Number of traffic metering actions pre-configured. > + * If set to 0, PMD will allocate meters dynamically. > + * @see RTE_FLOW_ACTION_TYPE_METER > + */ > + uint32_t nb_meters; > +}; > + > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice. > + * > + * Configure flow rules module. > + * To pre-allocate resources as per the flow port attributes > + * this configuration function must be called before any flow rule is created. > + * Must be called only after Ethernet device is configured, but may be called > + * before or after the device is started as long as there are no flow rules. > + * No other rte_flow function should be called while this function is invoked. > + * This function can be called again to change the configuration. > + * Some PMDs may not support re-configuration at all, > + * or may only allow increasing the number of resources allocated. Following comment from Ivan looks good to me * Pre-configure the port's flow API engine. * * This API can only be invoked before the application * starts using the rest of the flow library functions. * * The API can be invoked multiple times to change the * settings. The port, however, may reject the changes. > + * > + * @param port_id > + * Port identifier of Ethernet device. > + * @param[in] port_attr > + * Port configuration attributes. > + * @param[out] error > + * Perform verbose error reporting if not NULL. > + * PMDs initialize this structure in case of error only. > + * > + * @return > + * 0 on success, a negative errno value otherwise and rte_errno is set. > + */ > +__rte_experimental > +int > +rte_flow_configure(uint16_t port_id, Should we couple, setting resource limit hint to configure function as if we add future items in configuration, we may pain to manage all state. Instead how about, rte_flow_resource_reserve_hint_set()? > + const struct rte_flow_port_attr *port_attr, > + struct rte_flow_error *error); I think, we should have _get function to get those limit numbers otherwise, we can not write portable applications as the return value is kind of boolean now if don't define exact values for rte_errno for reasons. > + > #ifdef __cplusplus > } > #endif > diff --git a/lib/ethdev/rte_flow_driver.h b/lib/ethdev/rte_flow_driver.h > index f691b04af4..5f722f1a39 100644 > --- a/lib/ethdev/rte_flow_driver.h > +++ b/lib/ethdev/rte_flow_driver.h > @@ -152,6 +152,11 @@ struct rte_flow_ops { > (struct rte_eth_dev *dev, > const struct rte_flow_item_flex_handle *handle, > struct rte_flow_error *error); > + /** See rte_flow_configure() */ > + int (*configure) > + (struct rte_eth_dev *dev, > + const struct rte_flow_port_attr *port_attr, > + struct rte_flow_error *err); > }; > > /** > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map > index c2fb0669a4..7645796739 100644 > --- a/lib/ethdev/version.map > +++ b/lib/ethdev/version.map > @@ -256,6 +256,9 @@ EXPERIMENTAL { > rte_flow_flex_item_create; > rte_flow_flex_item_release; > rte_flow_pick_transfer_proxy; > + > + # added in 22.03 > + rte_flow_configure; > }; > > INTERNAL { > -- > 2.18.2 >