From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [RFC v2] Generic flow director/filtering/classification API Date: Wed, 9 Nov 2016 12:07:36 +0100 Message-ID: <20161109110736.GU5733@6wind.com> References: <20160705181646.GO7621@6wind.com> <20160929171053.GP17252@6wind.com> <20161102111303.GB5733@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "dev@dpdk.org" , Thomas Monjalon To: "Zhang, Helin" , "Zhao1, Wei" , Ajit Khaparde , Alejandro Lucero , Evgeny Schemeilin , Jing Chen , Jingjing Wu , Konstantin Ananyev , Maciej Czekaj , Matej Vido , Nelson Escobar , Rahul Lakkireddy , Rasesh Mody , Sony Chacko , Wenzhuo Lu , Yong Wang , Yuanhan Liu , Nelio Laranjeiro Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id DB8E1DE0 for ; Wed, 9 Nov 2016 12:07:45 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id t79so293279662wmt.0 for ; Wed, 09 Nov 2016 03:07:45 -0800 (PST) Content-Disposition: inline In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Helin and PMD maintainers, On Tue, Nov 08, 2016 at 01:31:05AM +0000, Zhang, Helin wrote: > Hi Adrien > > Any update on the v1 APIs? We are struggling on that, as we need that for our development. > May I bring another idea to remove the blocking? > Can we send out the APIs with PMD changes based on our understaning of the RFC we discussed recenlty on community? Then you can just update any modification on top of it, or ask the submittors to change with your review comments? > Any comments on this idea? If not, then we may go this way. I guess this might be the most efficient way. Thank you very much! Not wanting to hold back anyone's progress anymore (not that I was doing it on purpose), here's my work tree with the updated and functional API (rte_flow branch based on top of v16.11-rc3) while I'm preparing the patchset for official submission: https://github.com/am6/dpdk.org/tree/rte_flow As a work in progress, this branch is subject to change. API 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. -- Adrien Mazarguil 6WIND