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 C3ECBA04A8; Mon, 7 Feb 2022 19:25:00 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8CB00410F3; Mon, 7 Feb 2022 19:25:00 +0100 (CET) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) by mails.dpdk.org (Postfix) with ESMTP id 79A45410EA for ; Mon, 7 Feb 2022 19:24:58 +0100 (CET) Received: by mail-il1-f170.google.com with SMTP id z18so11844377ilp.3 for ; Mon, 07 Feb 2022 10:24:58 -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=uA4cksmuAxZ8iJAyR3xkD1r0RrrGBKTIBDJxqk3err0=; b=TT8mHxsXaaRtEBkUaPQEHqlh9qhi9AKEOlikqE4xIOURKrUYvj5yxlhXtmGtWq7CSi E8hlbbY7LAOYf6gudToCE/UyZv2oltQeX8Ut9++bwSQtWrgcMz39dgcvT6sbkWVMgdoH FrS6SYFayqhZKP+jN3cgvxHU4gjZYyTucJTjhJrHJJQVYlVXOkSlqiYoS06adroUts9c iDtZt5lsYGYWuf8GLqPaEDLkSHuwGEruNck0NGBopF1TIF97bqwRw0nYJMqm2dr3iSH4 nhLYoyS5p/jHVjTHACTiKF2mYUntGL++TdFGbQuaprOwCg2WDuSKhayXEbPYbYKgrAe+ mkKQ== 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=uA4cksmuAxZ8iJAyR3xkD1r0RrrGBKTIBDJxqk3err0=; b=WllfURylvL8Xu4oE53F3ViBvkReoB9MIop0d8mgaZqASXoLauJnhHNCpdWhB5dR4Kn UQdvc6aCtD4oQgTYwdu8aK6XbCgioQiplkeI6s2UAIcHELD0N8L23jGRJfkas6y1YrRo B3jHo44khd/GM6NYBthrdfj+4w4FOvj+JjixMXuhwEOilWdlN4T86dkOH5e9y+mdS3TF aotnY5JtL3nAU2aE3LLdGADOnJuGVdc4BrGD9mDNJvskDo6CftroO5+kXWg/MxPeQ3LB d5bqX6RIABympykdiKfRwsUtz3mPRgpHwmsu9mPwsKsD2eMvUFsp7psWbfYYwREr4ZQP wjRA== X-Gm-Message-State: AOAM533oBI4Qbb5EjDq23Fk2WbPeO/OiMuz9YQS9wId019Jxzf9ok2FE Nm99zZzI8N8kbsQH65/nVR4DX8oWSNjLxxWH2N8= X-Google-Smtp-Source: ABdhPJx2WAZw/JY7XWUZYwxrQHynhBlRVVsXFmckIWTmyCR1tT+I3WqXXV/J9o4QLdylix0abJpNstrv5xgVy7w7Utc= X-Received: by 2002:a05:6e02:160b:: with SMTP id t11mr417200ilu.75.1644258297709; Mon, 07 Feb 2022 10:24:57 -0800 (PST) MIME-Version: 1.0 References: <20220118153027.3947448-1-akozyrev@nvidia.com> <20220206032526.816079-1-akozyrev@nvidia.com> <20220206032526.816079-2-akozyrev@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Mon, 7 Feb 2022 23:54:31 +0530 Message-ID: Subject: Re: [PATCH v3 01/10] ethdev: introduce flow pre-configuration hints To: Alexander Kozyrev Cc: dpdk-dev , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , "mohammad.abdul.awal@intel.com" , Qi Zhang , Jerin Jacob , Ajit Khaparde , "Richardson, Bruce" 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, Feb 7, 2022 at 11:30 PM Alexander Kozyrev wrote: > > On Monday, February 7, 2022 9:52 Jerin Jacob wrote: > > On Sun, Feb 6, 2022 at 8:56 AM 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. > > > > > > The rte_flow_info_get() is available to retrieve the information about > > > supported pre-configurable resources. Both these functions must be called > > > before any other usage of the flow API engine. > > > > > > Signed-off-by: Alexander Kozyrev > > > --- > > > doc/guides/prog_guide/rte_flow.rst | 37 ++++++++++++ > > > doc/guides/rel_notes/release_22_03.rst | 4 ++ > > > lib/ethdev/rte_flow.c | 40 +++++++++++++ > > > lib/ethdev/rte_flow.h | 82 ++++++++++++++++++++++++++ > > > lib/ethdev/rte_flow_driver.h | 10 ++++ > > > lib/ethdev/version.map | 4 ++ > > > 6 files changed, 177 insertions(+) > > > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > > index b4aa9c47c2..5b4c5dd609 100644 > > > --- a/doc/guides/prog_guide/rte_flow.rst > > > +++ b/doc/guides/prog_guide/rte_flow.rst > > > @@ -3589,6 +3589,43 @@ Return values: > > > > > > - 0 on success, a negative errno value otherwise and ``rte_errno`` is set. > > > > > > +Flow engine configuration > > > +------------------------- > > > + > > > +Configure flow API management. > > > + > > > +An application may provide some hints at the initialization phase about > > > +rules engine configuration and/or expected flow rules characteristics. > > > > IMO, We can explicitly remove _hint_ in the documentation. > > When we add new paramers to configure, it may not be hit. > > > > > +These hints may be used by PMD to pre-allocate resources and configure > > NIC. > > > > hints->parameters > > Sounds good, let's call them parameters and PDM will decide to use them or not anyway. > > > + */ > > > +struct rte_flow_port_attr { > > > + /** > > > + * Version of the struct layout, should be 0. > > > + */ > > > + uint32_t version; > > > > IMO, it is not concluded to use the version in the public API. > > Yes, there is ongoing discussion on how to properly address versioning right now. > But I would like to proceed with this API without having to wait the final decision on that. > My API is experimental and it is possible to switch to any versioning model after. + @Richardson, Bruce On the same note, since it is experimental, we can add the version when we needed. I think, the primary pushback is application should not be aware of version, instead, implementation probe the version and adjust accordingly. IMO, In order to make forward progress, I suggest having the next version of the patch with without version and we can introduce this topic to TB for a final decision one way or another. > > > > > > + /** > > > + * Number of counter actions pre-configured. > > > + * @see RTE_FLOW_ACTION_TYPE_COUNT > > > + */ > > > + uint32_t nb_counters; > > > + /** > > > + * Number of aging flows actions pre-configured. > > > + * @see RTE_FLOW_ACTION_TYPE_AGE > > > + */ > > > + uint32_t nb_aging_flows; > > > + /** > > > + * Number of traffic metering actions pre-configured. > > > + * @see RTE_FLOW_ACTION_TYPE_METER > > > + */ > > > + uint32_t nb_meters; > > > +}; > > > + > > > +/** > > > + * @warning > > > + * @b EXPERIMENTAL: this API may change without prior notice. > > > + * > > > + * Retrieve configuration attributes supported by the port. > > > + * > > > + * @param port_id > > > + * Port identifier of Ethernet device. > > > + * @param[in] port_attr > > > > By default all parameters are "in", no need for additional "in" for just input. > > "in" or "out" is a part of description of every pointer parameter throughout rte_flow.h Ack.