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 72699A04A5; Tue, 25 Jan 2022 19:44:29 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E9B0941174; Tue, 25 Jan 2022 19:44:28 +0100 (CET) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by mails.dpdk.org (Postfix) with ESMTP id 49CC341161 for ; Tue, 25 Jan 2022 19:44:28 +0100 (CET) Received: by mail-il1-f175.google.com with SMTP id 15so3342047ilg.8 for ; Tue, 25 Jan 2022 10:44:28 -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=zd4PT5RYq6NdW7IkjtvP6qmqW9VnU1Y84f6GZiL1fTI=; b=C+vie/XC4i/Gu5lB65ov2qBZ7h4Ur/4CHzPXX4zEwq8noLl0n8HzPE3JUEYmqi9k/h kbQ/hNgzSJ4U9K/FHglDG8e7Q/RcdhSDnfhPg2AcFirpVkyiKwRp0hU+zBN3X/1UBiVp 4KcFoKT2EenuOXBu2cGpNArAFeehui64nUiBYMoPxdEyGXfNQOIp/wOjF7lJOs9IJqfr lTBxvhY1fmzA8+qgjOxXYm32h1QH/5NWOC7hD1eh7o6ffc5Q65vsx0WIpEmyvjLL663P toqQttFwvep/P++1YvIDesljuI3uPWyUQNxbkFYTDRGCulje/5GjSDG4HfSo26+rUUB3 jiqQ== 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=zd4PT5RYq6NdW7IkjtvP6qmqW9VnU1Y84f6GZiL1fTI=; b=VFmhrR99WXVDFpMsc49jtG9EGS2qcac3pvv/vjIliL9k+nB+Cc9Prlc7Hf9RGeb8Rh AMCZNkkJZ8GCbpP0pDhjoq6hhfT4YgIsiVXVJy21T0mzCQqT0NQl8OwFrpgnRHw9sXP6 LbAfgTz6men8FzS7y3z+NFsNZtAfnSRFq1k2WNxGTm2lDk27hAEh7LwUOBc/IPXPaxqm lj9hmrp2qXF2Guq8i61/pW1GRBB/z2skCWHTlSwaqftwTELhRM69WWzW/Tvay0Fcyq+p TchrxpnLFNwm8YtBas39kPweO8sneRb7ojM1VM+9pKsGeMd39pxxghcAVUee/TVsfOHl h+YA== X-Gm-Message-State: AOAM533Xj4i/wvF/szgFfjgTPgC+AvbMzUv855pI9uTZL8v3JVUNqm9t wWcozl62NBcznf14gj5mayC1smpxuW/8Ff5tRMQ= X-Google-Smtp-Source: ABdhPJwipihmAWNP7tYb5ooCdN0+97m+Muib1mEYvzCvmPlYwbdE6cPrXLpj6mG0OOpkcOJ/jGdWQEyV6rXPcXFmjSk= X-Received: by 2002:a92:6802:: with SMTP id d2mr12946449ilc.75.1643136266452; Tue, 25 Jan 2022 10:44:26 -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: Jerin Jacob Date: Wed, 26 Jan 2022 00:14:00 +0530 Message-ID: Subject: Re: [PATCH v2 01/10] ethdev: introduce flow pre-configuration hints To: Alexander Kozyrev Cc: Ajit Khaparde , dpdk-dev , Ori Kam , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , 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 Tue, Jan 25, 2022 at 6:58 AM Alexander Kozyrev wrote: > > On Monday, January 24, 2022 12:41 Ajit Khaparde wrote: > > On Mon, Jan 24, 2022 at 6:37 AM Jerin Jacob > > wrote: > > > > Ok, I'll adopt this wording in the v3. > > > > > + * > > > > + * @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 > Port attributes are the hints, PMD can safely ignore anything that is not supported/deemed unreasonable. > Having several functions to call instead of one configuration function seems like a burden to me. If we add a lot of features which has different state it will be difficult to manage. Since it is the slow path and OPTIONAL API. IMO, it should be fine to have a separate API for a specific purpose to have a clean interface. > > > > > > > > > > > > > + 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 > We had this discussion in RFC. The limits will vary from NIC to NIC and from system to > system, depending on hardware capabilities and amount of free memory for example. > It is easier to reject a configuration with a clear error description as we do for flow creation. In that case, we can return a "defined" return value or "defined" errno to capture this case so that the application can make forward progress to differentiate between API failed vs dont having enough resources and move on.