From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 975E5370 for ; Thu, 15 Dec 2016 13:20:39 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP; 15 Dec 2016 04:20:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,351,1477983600"; d="scan'208";a="42903996" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.29]) ([10.237.220.29]) by fmsmga006.fm.intel.com with ESMTP; 15 Dec 2016 04:20:37 -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: <57fdc1d0-1d2b-da61-481b-358aed8d91a2@intel.com> Date: Thu, 15 Dec 2016 12:20:36 +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: 8bit 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, 15 Dec 2016 12:20:40 -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. Hi Adrien, I would like to remind that there are driver patch sets depends to this patch. New version of this patch should give some time to drivers to re-do (if required) the patchsets before integration deadline. Thanks, ferruh > 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? > <...>