From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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=5oZjGFsMuE8VN8NuCLGOrWzRsSYDDIxCAWp6YUw1oA0=; b=HCy+8eI1G0K7otZMawOEAdpa05huZCj4fD4NbMmSoYNx29+iUPYnu8UDesdGuaS3K/ cYB4gq1J9nfQU9QgZ5ErZ00mTaaLQbGjTzJ0A8bAbOW7qsJsmNWgWrZe5ABL4RTh7t75 AtNWQHjsO33iiZIRXaz3553oNvhgmnXdmnPo0LI8V/K9YCWeRUYp6UXJVqlvrFHbvTaU 4Onr0cTUW5Bf5OM87lNHU9X+uv1fgRUtVGIAj9Iafqmc0Mcnkh8PBg6pRkOqsMpydTla Q4Iko7h+e4Day4Js8V4GD4myMNrMgmiX+n0aJqs/duc2BVA92QuFnUi5g13QYrUAYxm2 iuww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5oZjGFsMuE8VN8NuCLGOrWzRsSYDDIxCAWp6YUw1oA0=; b=jkCAGBerLuHCjKriKuE+OPevqSDnY/tGEg6m8vG1XyOldCSWliLc0D7muzT1rQRYF2 9NRvJQUMxXxWe3WVAGuytNDwfXYk62GVj5WBtV/0szwY2SEjKhMEYw9QUDcZkT3IE0Fi Q9ORJIrN4DHUnqyh60aUovXH7Oq6DF2vyUXQ7W1ax5x+x7FFUQNln1rGCGsIQ/p35D3y nmX4eFC7HGHzt73zQ1HuFLQeukE9LPhDIQSRhd0DNG+BDtDAvkODA9Mjq0UOJf+L7VW+ xwptatknxeGYWCEw66XCTcaDkUgJaaDxOPvtIDOXy8QTTTCeeVqMwg8Iji6CT4hPVlZf yUbQ== X-Gm-Message-State: ABUngve0hI+OD8921YsifxF8bx1Xs7BDWZfAtbSAFZwk1byXzZEeaS1WHZfC7VRZR/9pzp6B X-Received: by 10.28.230.197 with SMTP id e66mr3047397wmi.12.1478689665543; Wed, 09 Nov 2016 03:07:45 -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 o62sm24915679wmg.9.2016.11.09.03.07.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 03:07:44 -0800 (PST) Date: Wed, 9 Nov 2016 12:07:36 +0100 From: Adrien Mazarguil 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 Cc: "dev@dpdk.org" , Thomas Monjalon 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 Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [RFC v2] Generic flow director/filtering/classification API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 11:07:46 -0000 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