From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 647322A66 for ; Thu, 8 Dec 2016 18:56:43 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 08 Dec 2016 09:56:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,320,1477983600"; d="scan'208";a="15524378" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.29]) ([10.237.220.29]) by orsmga002.jf.intel.com with ESMTP; 08 Dec 2016 09:56:28 -0800 To: Adrien Mazarguil References: <20161208151935.GK10340@6wind.com> Cc: dev@dpdk.org, Thomas Monjalon , Pablo de Lara , Olivier Matz From: Ferruh Yigit Message-ID: Date: Thu, 8 Dec 2016 17:56:27 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161208151935.GK10340@6wind.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow) 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 17:56:44 -0000 On 12/8/2016 3:19 PM, Adrien Mazarguil wrote: > Hi Ferruh, > > On Fri, Dec 02, 2016 at 04:58:53PM +0000, Ferruh Yigit wrote: >> Hi Adrien, >> >> On 11/16/2016 4:23 PM, Adrien Mazarguil wrote: >>> As previously discussed in RFC v1 [1], RFC v2 [2], with changes >>> described in [3] (also pasted below), here is the first non-draft series >>> for this new API. >>> >>> Its capabilities are so generic that its name had to be vague, it may be >>> called "Generic flow API", "Generic flow interface" (possibly shortened >>> as "GFI") to refer to the name of the new filter type, or "rte_flow" from >>> the prefix used for its public symbols. I personally favor the latter. >>> >>> While it is currently meant to supersede existing filter types in order for >>> all PMDs to expose a common filtering/classification interface, it may >>> eventually evolve to cover the following ideas as well: >>> >>> - Rx/Tx offloads configuration through automatic offloads for specific >>> packets, e.g. performing checksum on TCP packets could be expressed with >>> an egress rule with a TCP pattern and a kind of checksum action. >>> >>> - RSS configuration (already defined actually). Could be global or per rule >>> depending on hardware capabilities. >>> >>> - Switching configuration for devices with many physical ports; rules doing >>> both ingress and egress could even be used to completely bypass software >>> if supported by hardware. >>> >>> [1] http://dpdk.org/ml/archives/dev/2016-July/043365.html >>> [2] http://dpdk.org/ml/archives/dev/2016-August/045383.html >>> [3] http://dpdk.org/ml/archives/dev/2016-November/050044.html >>> >>> Changes since RFC v2: >>> >>> - New separate VLAN pattern item (previously part of the ETH definition), >>> found to be much more convenient. >>> >>> - Removed useless "any" field from VF pattern item, the same effect can be >>> achieved by not providing a specification structure. >>> >>> - Replaced bit-fields from the VXLAN pattern item to avoid endianness >>> conversion issues on 24-bit fields. >>> >>> - Updated struct rte_flow_item with a new "last" field to create inclusive >>> ranges. They are defined as the interval between (spec & mask) and >>> (last & mask). All three parameters are optional. >>> >>> - Renamed ID action MARK. >>> >>> - Renamed "queue" fields in actions QUEUE and DUP to "index". >>> >>> - "rss_conf" field in RSS action is now const. >>> >>> - VF action now uses a 32 bit ID like its pattern item counterpart. >>> >>> - Removed redundant struct rte_flow_pattern, API functions now expect >>> struct >>> rte_flow_item lists terminated by END items. >>> >>> - Replaced struct rte_flow_actions for the same reason, with struct >>> rte_flow_action lists terminated by END actions. >>> >>> - Error types (enum rte_flow_error_type) have been updated and the cause >>> pointer in struct rte_flow_error is now const. >>> >>> - Function prototypes (rte_flow_create, rte_flow_validate) have also been >>> updated for clarity. >>> >>> Additions: >>> >>> - Public wrapper functions rte_flow_{validate|create|destroy|flush|query} >>> are now implemented in rte_flow.c, with their symbols exported and >>> versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added. >>> >>> - A separate header (rte_flow_driver.h) has been added for driver-side >>> functionality, in particular struct rte_flow_ops which contains PMD >>> callbacks returned by RTE_ETH_FILTER_GENERIC query. >>> >>> - testpmd now exposes most of this API through the new "flow" command. >>> >>> What remains to be done: >>> >>> - Using endian-aware integer types (rte_beX_t) where necessary for clarity. >>> >>> - API documentation (based on RFC). >>> >>> - testpmd flow command documentation (although context-aware command >>> completion should already help quite a bit in this regard). >>> >>> - A few pattern item / action properties cannot be configured yet >>> (e.g. rss_conf parameter for RSS action) and a few completions >>> (e.g. possible queue IDs) should be added. >>> >> >> <...> >> >> I was trying to check driver filter API patches, but hit a few compiler >> errors with this patchset. >> >> [1] clang complains about variable bitfield value changed from -1 to 1. >> Which is correct, but I guess that is intentional, but I don't know how >> to tell this to clang? >> >> [2] shred library compilation error, because of missing rte_flow_flush >> in rte_ether_version.map file >> >> [3] bunch of icc compilation errors, almost all are same type: >> error #188: enumerated type mixed with another type > > Thanks for the report, I'll attempt to address them all in v2. However icc > error #188 looks like a pain, I think I can work around it but do we really > not tolerate the use of normal integers inside enum fields in DPDK? If this warning is not improving the code, and community agree on it, it is possible to disable warning by adding "-wd188" to test-pmd Makefile for ICC compiler.