From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) by dpdk.org (Postfix) with ESMTP id E84102BAE for ; Fri, 21 Apr 2017 12:38:21 +0200 (CEST) Received: by mail-wr0-f179.google.com with SMTP id c55so52140799wrc.3 for ; Fri, 21 Apr 2017 03:38:21 -0700 (PDT) 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:content-transfer-encoding:in-reply-to :user-agent; bh=gspBamzj7t+kAP3cB50KHFmVL9BiwrBWTKW/Jg0yAz8=; b=DpFpNCaGku3oYBngdPmHIjLcImVg6LV665MOyI+cOmUnQRn7BYgZN/fYmMpitRI5IO mRC11NZWoF319zapH0q7n2U0n/yea9kuJFLeqtfWu5E8NLUcigbtG6fWqwcLgLZt3BYN g1VshnDbDNlPXKTdk0DOiTLyQ90b5sW+/wzRBKziYNT0E18Hx74d5g5C8/gWyNUrKAc5 hnKfQhVsdcLfsAVcqjEejvgnhhXvVVvhsWhM1AEWw2G4OjCR1dpEoDzopdBXWRLpFFG9 2aWKwq43VylB6vH3Ob9WgqWJ2bOsnLjecbSURvUSrUsuJPk9wKuCP3uyQ2FS5Pou9SZE QrGw== 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:content-transfer-encoding :in-reply-to:user-agent; bh=gspBamzj7t+kAP3cB50KHFmVL9BiwrBWTKW/Jg0yAz8=; b=fAdpKZj4vTpUsoC934wWLGbQYu6ZZ5SRSV+4RkLpwYfu4uVllPTVZ6z1jMqYY3z3RZ D9pD+Gyy2qZHrn79h+YML3Ha9t+lBaP9Iq3TAF01fd6BFt/jVI5NC1ek5FE7Tvln60Bv xOwasU2ip2yaL6kOt2jjWA6gSzk04XKUP1KtahZBdJLQ1Yz2nWdWyrxgMvQSl+/mqF6J LoxDhsnwCEu7VfUHISZcrz4w8ekBBuhe/1fEC/I5pmCQeUbb18NNk096nte39batTdEB 2W0EUUe6xzBV4XEarClOwGI8/lzloc9UR+hN3aYtHiB+o0RQ/8hTz1ul+MYvnacmEAqH TZhw== X-Gm-Message-State: AN3rC/5ZtyPPvq3y6ATI+BRlYOU45/SGGBW0Ic20DeVwQfX2O/ZR+qev U8oL+gt6BKWeedUI X-Received: by 10.223.171.8 with SMTP id q8mr11870903wrc.115.1492771101441; Fri, 21 Apr 2017 03:38:21 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id i21sm11128431wrc.50.2017.04.21.03.38.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 03:38:20 -0700 (PDT) Date: Fri, 21 Apr 2017 12:38:13 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Ferruh Yigit Cc: dev@dpdk.org, John McNamara , Maryam Tahhan Message-ID: <20170421103813.GH14914@bidouze.vm.6wind.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170420185448.19162-1-ferruh.yigit@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library 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, 21 Apr 2017 10:38:22 -0000 Hi Ferruh, On Thu, Apr 20, 2017 at 07:54:47PM +0100, Ferruh Yigit wrote: >DPDK works with packets, but some network administration tools works based on >flow information. > >This library is suggested to provide helper APIs to convert packet based >information to the flow records. Library header file has more comments on >how library works and provided APIs. > >Packets to flow conversion will cause performance drop, that is why this >conversion can be enabled and disabled dynamically by application. > >Initial implementation in mind is to provide support for IPFIX metering process >but library planned to be as generic as possible. And flow information provided >by this library is missing to implement full IPFIX features, but this is planned >to be initial step. > In order to be generic, would it not be interesting to specify the flow as a generic rte_flow_item list? Some specific IPFIX items are not expressed currently in rte_flow (e.g. packet size), but they could be added. This library could consist in an rte_flow_item to IPFIX translation. The inverse approach could be used, but seems backward to me. It makes more sense to support DPDK idioms and open them to standards by proper APIs than including standards in internals and introduce translation layers between DPDK components. >It is possible to define flow with various flow keys, but currently only one >type of flow defined in the library, which is more generic, and it offloads >fine grained flow analysis to the application. Library enables expanding for >other flow types. > I'm not sure I understand the purpose of this flow key, generic is too general of a hint to define the possible cases. However, my intuition is that the flow type describe a filter to restrict the flow classification to specific patterns instead of all supported ones. This library thus resembles using the action RTE_FLOW_ACTION_TYPE_COUNT, then retrieved using rte_flow_query_count. The rte_flow_item aggregated with the rte_flow_query_count structure could be sufficient to derive IPFIX meters? An application could then use this data for its IPFIX support. >It will be more beneficial to shape this library to cover more use cases, please >feel free to comment on possible other use case and desired functionalities. > >Thanks, >ferruh > >cc: John McNamara >cc: Maryam Tahhan > >Ferruh Yigit (1): > flow_classify: add librte_flow_classify library > > config/common_base | 5 + > doc/api/doxy-api-index.md | 1 + > doc/api/doxy-api.conf | 1 + > doc/guides/rel_notes/release_17_05.rst | 1 + > lib/Makefile | 2 + > lib/librte_flow_classify/Makefile | 50 +++++ > lib/librte_flow_classify/rte_flow_classify.c | 34 ++++ > lib/librte_flow_classify/rte_flow_classify.h | 202 +++++++++++++++++++++ > .../rte_flow_classify_version.map | 10 + > 9 files changed, 306 insertions(+) > create mode 100644 lib/librte_flow_classify/Makefile > create mode 100644 lib/librte_flow_classify/rte_flow_classify.c > create mode 100644 lib/librte_flow_classify/rte_flow_classify.h > create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map > >-- >2.9.3 > -- Gaëtan Rivet 6WIND