From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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=l0fUfQupnWV+V5E6VLQ6ES0djGGdqVqrkiXscf99Sqg=; b=0rHPNvcfzlNuxeh7Bpwe7bEMqH8sTthIgtbI2wMW0X76naQQ4X6V+NPTMpM0WVUKip NVtgKP0ItZTQO7mMzQkZWgl5h3X8I9YsnyAmywpO820w6mvb3CcMylzW1WGpumy/xLIP XgDOUkJYqTaUUuS1+//JXMgIwfm0lWp9TislD7dfbh0aLWUGCflAfW6hlFdtENEL7FMH H0pMUNSB2LamigE46jx8Pe4eFpOJ0maH+AIMRsQqi5pVwHWXTL7u1CiBxDC9V7pGyqmw juJodXvfLgKeznbIX/EkCHzlbmgAwZRL7O96EPyU3SF/xIr2db0hriZXgkDVy9gvjWhY W+Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=l0fUfQupnWV+V5E6VLQ6ES0djGGdqVqrkiXscf99Sqg=; b=CE/q6RXR5FYvxXdu0bSaUZReBFpfPHBOnHnArWsHZvF9Hi3XBVNZgXd8cHMhZ5TC4y 82TvUZZubpkxzGqJXklx0Kcj9tAWdl1FngNQ4ncHANowUtgsAKCWAai+Nt8oRt1vaFEi Kf3SsNQNaS4CEFVH5zumI08X3QVU8vSgpQbo7JfYPODD1qhP3jityPmqXrCBpVgnPrNq QAAJMuKcdslDmKOGu9Ho/oZ/YLrYTTHNOLxyQYzf5otZhpB6aUO5v/XedAVaVXO2r3Qw IxECCd9czp9P+c+hpNfXpjCX8i0pB5oDsZGT8VuXHysWvpzTVMZgMgNE7pIvO+HsWCBr XPdA== X-Gm-Message-State: AIkVDXKvVEMUz4R8IUi9Noyhx5Wmm+FrhpRa+nHxTa/TLXjY0OutAzoaTR1Kbkm6HZ30Hstq X-Received: by 10.194.0.229 with SMTP id 5mr1831199wjh.55.1481876539904; Fri, 16 Dec 2016 00:22:19 -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 135sm2226507wmh.14.2016.12.16.00.22.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Dec 2016 00:22:18 -0800 (PST) Date: Fri, 16 Dec 2016 09:22:11 +0100 From: Adrien Mazarguil To: Ferruh Yigit Cc: dev@dpdk.org, Thomas Monjalon , Pablo de Lara , Olivier Matz 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 Content-Disposition: inline In-Reply-To: <57fdc1d0-1d2b-da61-481b-358aed8d91a2@intel.com> 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: Fri, 16 Dec 2016 08:22:20 -0000 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