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 2B44BA04AD; Mon, 24 Jan 2022 18:40:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9DC5541170; Mon, 24 Jan 2022 18:40:57 +0100 (CET) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by mails.dpdk.org (Postfix) with ESMTP id BADCE40040 for ; Mon, 24 Jan 2022 18:40:55 +0100 (CET) Received: by mail-io1-f47.google.com with SMTP id i62so4763321ioa.1 for ; Mon, 24 Jan 2022 09:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZgWGEEfOblioRT4Y43LZm+0QTAFJd/7ypvcP8ytUetQ=; b=appRWSKd/KeS4YHvR4zWvvH4Jf1SZJoi+cb2CHftsEd5Vz2aas3JKsB+iS34JFngoG nQUsTsKqd+qVZAP6PyLTtq/FoKr7Svj9QreZWDJxkFcu7ft0DJpWPCsvXm8CFCFwUl6N vw36K2Uih/WzC4B506cpoWW2jD/DotsP/6G8A= 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=ZgWGEEfOblioRT4Y43LZm+0QTAFJd/7ypvcP8ytUetQ=; b=ASx0CGDWTbp1kviMIFYrUwK41zB34wMH4dfrkDJ2dbzgSaBfU+GcJqIBCz3IYcr39+ 9k8owsVc9kRKGL9wgIMS9YQzrL++50pcK45CmIj6Qy3JDmaNt5zKx9KwaEGqZ0gLacc+ jX2A8p00gks+mAaHX6IjcmkTJk/9kZ+Th6HbzaFGSrH4ixmp2BkGMJp+RyCQAKznH/4p 1FtuIGLD8KTUC1oiUOgszkRyE+tpgob68wipQiiawQeNvevmgG8srXwVGpDen97AQ/VW f0VzIdclB1+rYSf/kxyljrQ3gaVnvhHsavh3jiGaCkMOM8cJWd5LduvDV0Pycrq5THmK 26+w== X-Gm-Message-State: AOAM532DzxE1JdMpxS7HdT87j/9VplK6KMcbD64uuia0OQz3OmVN/fO1 MG1u9isG11Ro3DpW5t027Ba29cem+gBifQHB1xEm5A== X-Google-Smtp-Source: ABdhPJxyr+hWLOazleox1SzOe70IWZn3DuksOdRab+7rdiA87aX05rh7GZJnckopiCZtTIP8hJuGSzzgv9jchX/UnRc= X-Received: by 2002:a02:a609:: with SMTP id c9mr5830506jam.84.1643046054936; Mon, 24 Jan 2022 09:40:54 -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: From: Ajit Khaparde Date: Mon, 24 Jan 2022 09:40:39 -0800 Message-ID: Subject: Re: [PATCH v2 01/10] ethdev: introduce flow pre-configuration hints To: Jerin Jacob Cc: Alexander Kozyrev , dpdk-dev , Ori Kam , Thomas Monjalon , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , mohammad.abdul.awal@intel.com, Qi Zhang , Jerin Jacob 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 Mon, Jan 24, 2022 at 6:37 AM Jerin Jacob wrote: > > 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()? +1 > > > > + 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. +1