From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [PATCH 00/22] Generic flow API (rte_flow) Date: Fri, 16 Dec 2016 09:22:11 +0100 Message-ID: <20161216082211.GA10340@6wind.com> References: <20161208151935.GK10340@6wind.com> <57fdc1d0-1d2b-da61-481b-358aed8d91a2@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, Thomas Monjalon , Pablo de Lara , Olivier Matz To: Ferruh Yigit Return-path: Received: from mail-wj0-f179.google.com (mail-wj0-f179.google.com [209.85.210.179]) by dpdk.org (Postfix) with ESMTP id 583F7377C for ; Fri, 16 Dec 2016 09:22:20 +0100 (CET) Received: by mail-wj0-f179.google.com with SMTP id xy5so86026046wjc.0 for ; Fri, 16 Dec 2016 00:22:20 -0800 (PST) Content-Disposition: inline In-Reply-To: <57fdc1d0-1d2b-da61-481b-358aed8d91a2@intel.com> 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 Thu, Dec 15, 2016 at 12:20:36PM +0000, Ferruh Yigit wrote: > 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. Hi Ferruh, I intend to send v2 (including all the requested changes and fixes) shortly, most likely today. -- Adrien Mazarguil 6WIND