From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id B42162A5E for ; Thu, 8 Dec 2016 16:09:16 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id g23so221478494wme.1 for ; Thu, 08 Dec 2016 07:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=EvdFl9uXhkFppmQEMYB9gsWg1lTubAuVLLOoqs5kzPs=; b=XttcEjJIYMZgzW82AwXJtSm07mFcqDzHuvn8aJqn5qn8SKPJIuTcU2gLBwBJ0LK10g KqXo/2bumwV6X2NYYtzYfbog8zG+mbpTkgJ+cOG4rX5gcC7iph2BVEqg2JODJmWpG3ig 5iAiBbSRtqDxOfQz/HNw2zCZ72SFyALQ8PKNHWCSS+WNfS7JEpE5ORqpEtCuOBy4WGsR xvH8BarMigTPT5rqm0SVtiNmUAbVqIJ4dr8cP3EGKmfSzQGr9DG5gqMmCF7ixJvguMus mRIA2SOXh61Ct3/7dwV7/7APU1qZDdnVF0ZsDWUTALbG8T/7SisdOBMXQ96D1m9X2nNQ U0ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=EvdFl9uXhkFppmQEMYB9gsWg1lTubAuVLLOoqs5kzPs=; b=kiqwJew45FWeOYs3u3VtlQc2r0pixG6+rYu7kzrI86IL7fBqbkv9vwVgj3F4/FPHN9 Ew6gKrfpEsVcZnN/WhL6o75q7MZvxiK+Gs49Em5XEeNGD9uqKal0Bmm1yxfa4jNJ0/8h yDabyINicPzhHkXXpbFP4RIM1oTSi4nDY7JGkYWgF0L7XgBv3zKgBvcDNPUkaWdba+1Q eFFlbyG8ZlPTty2Q8oIVq1Q65Q+js5dl7Ofdoq4alMKrMpR9tOz4bwEA91/YAhJoKuIN /BaY1dGtrbOhp+gFlhbaoqrNKqlGya/Hx2+Zv/B3/EXMfoP2KoVLDbxrlEZ+eldKqsiS IaEw== X-Gm-Message-State: AKaTC00uZb0WVjUVkx6ULUu3t9yGIPM3bTnx8pNteIZawPklMS0MaeBfVlqa7T/qdRUOslHD X-Received: by 10.28.170.134 with SMTP id t128mr2522585wme.29.1481209756423; Thu, 08 Dec 2016 07:09:16 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id kp5sm37512504wjb.8.2016.12.08.07.09.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Dec 2016 07:09:15 -0800 (PST) Date: Thu, 8 Dec 2016 16:09:08 +0100 From: Adrien Mazarguil To: "Chandran, Sugesh" Cc: Kevin Traynor , "dev@dpdk.org" , Thomas Monjalon , "De Lara Guarch, Pablo" , Olivier Matz , "sugesh.chandran@intel.comn" Message-ID: <20161208150908.GJ10340@6wind.com> References: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com> <59393e58-6c85-d2e5-1aab-a721fe9c933e@redhat.com> <20161201083652.GI10340@6wind.com> <7f65ba09-e6fe-d97a-6ab5-97e84a828a81@redhat.com> <2EF2F5C0CC56984AA024D0B180335FCB13EC330D@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13EC330D@IRSMSX102.ger.corp.intel.com> Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 15:09:16 -0000 Hi Sugesh, On Tue, Dec 06, 2016 at 06:11:38PM +0000, Chandran, Sugesh wrote: [...] > > >>> +int > > >>> +rte_flow_validate(uint8_t port_id, > > >>> + const struct rte_flow_attr *attr, > > >>> + const struct rte_flow_item pattern[], > > >>> + const struct rte_flow_action actions[], > > >>> + struct rte_flow_error *error); > > >> > > >> Why not just use rte_flow_create() and get an error? Is it less > > >> disruptive to do a validate and find the rule cannot be created, than > > >> using a create directly? > > > > > > The rationale can be found in the original RFC, which I'll convert to > > > actual documentation in v2. In short: > > > > > > - Calling rte_flow_validate() before rte_flow_create() is useless since > > > rte_flow_create() also performs validation. > > > > > > - We cannot possibly express a full static set of allowed flow rules, even > > > if we could, it usually depends on the current hardware configuration > > > therefore would not be static. > > > > > > - rte_flow_validate() is thus provided as a replacement for capability > > > flags. It can be used to determine during initialization if the underlying > > > device can support the typical flow rules an application might want to > > > provide later and do something useful with that information (e.g. always > > > use software fallback due to HW limitations). > > > > > > - rte_flow_validate() being a subset of rte_flow_create(), it is essentially > > > free to expose. > > > > make sense now, thanks. > [Sugesh] : We had this discussion earlier at the design stage about the time taken for programming the hardware, > and how to make it deterministic. How about having a timeout parameter as well for the rte_flow_* > If the hardware flow insert is timed out, error out than waiting indefinitely, so that application have some control over > The time to program the flow. It can be another set of APIs something like, rte_flow_create_timeout() Yes as discussed the existing API does not provide any timing constraints to PMDs, validate() and create() may take forever to complete, although PMDs are strongly encouraged to take as little time as possible. Like you suggested, this could be done through distinct API calls. The validate() function would also have its _timeout() counterpart since the set of possible rules could be restricted in that mode. > Are you going to provide any control over the initialization of NIC to define the capability matrices > For eg; To operate in a L3 router mode, software wanted to initialize the NIC port only to consider the L2 and L3 fields. > I assume the initialization is done based on the first rules that are programmed into the NIC.? Precisely, PMDs are supposed to determine the most appropriate device mode to use in order to handle the requested rules. They may even switch to another mode if necessary assuming this does not break existing constraints. I think we've discussed an atomic (commit-based) mode of operation through separate functions as well, where the application would attempt to create a bunch of rules at once, possibly making it easier for PMDs to determine the most appropriate mode of operation for the device. All of these may be added later according to users feedback once the basic API has settled. -- Adrien Mazarguil 6WIND