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 50608A0C47; Sun, 31 Oct 2021 18:27:38 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C79084068E; Sun, 31 Oct 2021 18:27:37 +0100 (CET) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by mails.dpdk.org (Postfix) with ESMTP id E561C40689 for ; Sun, 31 Oct 2021 18:27:36 +0100 (CET) Received: by mail-io1-f54.google.com with SMTP id h81so10140869iof.6 for ; Sun, 31 Oct 2021 10:27:36 -0700 (PDT) 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=ryFxqbXRzF9Z2nWNAq9OnGfLbdc2vLLO+JkH5fYd2ww=; b=I4r8uVtLxclp0wR+sHDHbdObTkNYy2Zc/lj3czCpbXxzctWHr0hSpl43NJ78VFBZ05 G2T69m7ak4CHg5E/WJGBrHvlq1ryKkVxKLd+TQArTuqsVaNkM+PofXxH6xAKMAKPZWXl 1decvYPv6njxqyA8/dyfOW26YEUe403MHEhn0= 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=ryFxqbXRzF9Z2nWNAq9OnGfLbdc2vLLO+JkH5fYd2ww=; b=0kzuR/krZsfslZXoM5+KZOsnubVolNkDJu/ZsQx3jx1GmHA2LcG7/S/SHutFV8Blj0 Ss6vjKuuXTC2cGIgEasMY6Qxfj05bVnxUQEEStlXJhJ1+bWKQxDPSUAGHhnPKaMiqgS4 Lfs4MGhQBlS9cd7QK8BVTfwIwJhfWL/LW183vj+WfdMEHxVaM/CPkrbLQm1wl8Da60n9 dJT0Lq6QCilFZN2aMQnbE04Lp+LPHG0PmXGYc43qlww7zNymomH5v4fywMXXj0XoQmG1 5gYmZq3jEeVvsO3z/vZIzBSW31P0Xg49a5253THiPotiDkXK2Oox1N0eiAWSLrYDzfOr efGw== X-Gm-Message-State: AOAM532Gjs9D7sHXzm7m1fksh82sPhDYErKw/nlkDwk6J3TQMRWyEtWK U9fBVuJf6mnL6H6Pn3wmdBM4tqjNXC2ufq8QSlHFIg== X-Google-Smtp-Source: ABdhPJzzghQgJMYfRK1gZPqLrJV4b8+zwS4u5knRtoWEJJi5+XaNsA5zNSPOKzahvbU6wtO6xQZk9SlI1jqc9ZXkDXw= X-Received: by 2002:a5d:878e:: with SMTP id f14mr17700238ion.111.1635701256194; Sun, 31 Oct 2021 10:27:36 -0700 (PDT) MIME-Version: 1.0 References: <20211006044835.3936226-1-akozyrev@nvidia.com> <20211006044835.3936226-2-akozyrev@nvidia.com> In-Reply-To: From: Ajit Khaparde Date: Sun, 31 Oct 2021 10:27:20 -0700 Message-ID: To: Ori Kam Cc: Alexander Kozyrev , dpdk-dev , NBU-Contact-Thomas Monjalon , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , "mohammad.abdul.awal@intel.com" , Qi Zhang , Jerin Jacob Kollanukkaran Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 1/3] ethdev: introduce flow pre-configuration hints 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 Sender: "dev" On Wed, Oct 13, 2021 at 6:15 AM Ori Kam wrote: > > Hi Ajit, > > > -----Original Message----- > > From: Ajit Khaparde > > Sent: Wednesday, October 13, 2021 7:11 AM > > Subject: Re: [PATCH 1/3] ethdev: introduce flow pre-configuration hints > > > > On Tue, Oct 5, 2021 at 9:48 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. > > This could get tricky. An application can avoid attempts to create flows for items/actions if it can get a > > hint that PMD cannot satisfy some of the hints provided. > > Also what if the application tries to configure a higher count than what the PMD/HW can support? > > It will be good if the hints can be negotiated. > > Something like this? > > Application could start with a set of hints. > > PMD can check what can be supported and return an updated set. > > Application stays within those values till it needs to resize. > > > > I don't like the negotaion approach since soon it will be impossible to maintain. > I don't know how many possible option there will and what each PMD will implement. > Also negotiation means that the PMD think he knows what is best and this is the opposite of > this feature as giving the application as much control as possible. > > Just like configure ethdev may fail and the application just get the error message. > What application should do with the hits is PMD dependent. > > For example application request 1M counter, this can even be system specific (to much memory) > if PMD can't allocate such number of counter it should fail with error message that lets the application > know if possible the max number of counters. How will the application know that the failure was because of counters and not because of meters or something else? > > Best, > Ori > > > > > > > Signed-off-by: Alexander Kozyrev > > > Suggested-by: Ori Kam > > > --- > > > lib/ethdev/rte_flow.h | 70 > > > +++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 70 insertions(+) > > > > > > diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index > > > 7b1ed7f110..c69d503b90 100644 > > > --- a/lib/ethdev/rte_flow.h > > > +++ b/lib/ethdev/rte_flow.h > > > @@ -4288,6 +4288,76 @@ rte_flow_tunnel_item_release(uint16_t port_id, > > > struct rte_flow_item *items, > > > uint32_t num_of_items, > > > struct rte_flow_error *error); > > > + > > > +/** > > > + * Flow engine configuration. > > > + */ > > > +__extension__ > > > +struct rte_flow_port_attr { > > > + /** > > > + * Version of the struct layout, should be 0. > > > + */ > > > + uint32_t version; > > > + /** > > > + * Memory size allocated for the flow rules management. > > > + * If set to 0, memory is allocated dynamically. > > > + */ > > > + uint32_t mem_size; > > > + /** > > > + * 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; > > > + /** > > > + * Resources reallocation strategy. > > > + * If set to 1, PMD is not allowed to allocate more resources on demand. > > > + * An application can only allocate more resources by calling the > > > + * configure API again with new values (may not be supported by PMD). > > > + */ > > > + uint32_t fixed_resource_size:1; }; > > > + > > > +/** > > > + * @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. > > > + * 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. > > > + * > > > + * @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, > > > + const struct rte_flow_port_attr *port_attr, > > > + struct rte_flow_error *error); > > > #ifdef __cplusplus > > > } > > > #endif > > > -- > > > 2.18.2 > > >