From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 2647728EE for ; Mon, 22 May 2017 11:13:30 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id e127so30086361wmg.1 for ; Mon, 22 May 2017 02:13:30 -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; bh=LkhEktNoxDSrAe+HYocMvtQbT6nETnWWA8ecfADbQz0=; b=NtHy4ZYkLSwj0XMMOnNuGeCksv9uVrMattjlTTdjnPLIJUuH4KVs4iCZSeewBR+hQK YWTx7sdT/ciNvWy57sCg3hdUUgzhaZ05A8XFl4Jx2l7x7DlTqnn4hgVa6QYGNJKy/2iz wEoP58EbnpUi6G2+N7vZjcZ2vWW+aAKvDoqBFPXRN8RP8fMyrtuHRjHpgCZcilAXl9Y8 Vd57I/KhAdIbK4l7rCVytBlJx79I5JiY81M4L71+/Or5vOLLqDiLYfPwYjqnxFLfqWik R4Mes79gkXDNhlSzRcix74O+gohYu94dOWdGddGLSK6BMxI2nDVYTC60okgiVXujpRAZ 3HvQ== 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; bh=LkhEktNoxDSrAe+HYocMvtQbT6nETnWWA8ecfADbQz0=; b=F6BMNndzzLEnOQS0arDYo1zI8RDWeTKrx43rACA4lHUPer5M9hCkTxnCu39GrneKLj P7iTBEaUvGr2HG+jZxN8+Dgx5EP0QNAZ6asZsJWj9sj7NTKIjhj3MRioDiVONc+ng+eD 31qV0o93SzHwcMHrtjmqfXgRluJW4z9LSpYc0z1CtCNxULwbJe/qEKqwAaCs3zxPkRsz wA+/H5zZzLPJC2gF+35ULRtlwIqwKR6MBaOpqsBB8thDVbHstsqm29inS9RETw9sRIXL rlhlnBX4ADytdfp7iy8eQ0V3ybQq59l5Ji4I4KeyMa+wERiE6oPtuKXC1bDx02Dsac8M ir2w== X-Gm-Message-State: AODbwcDY/h1OVk+AQqtQH8Pj62/Ij7CjO/Znw0nkEExRYLrlFQE0YDfs 2Ht8hFL9ccMWXo/B X-Received: by 10.28.207.207 with SMTP id f198mr26977758wmg.85.1495444410520; Mon, 22 May 2017 02:13:30 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id o200sm13294927wmg.22.2017.05.22.02.13.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 02:13:29 -0700 (PDT) Date: Mon, 22 May 2017 11:13:23 +0200 From: Adrien Mazarguil To: Thomas Monjalon Cc: =?utf-8?Q?Ga=C3=ABtan?= Rivet , "Ananyev, Konstantin" , "Yigit, Ferruh" , dev@dpdk.org, "Mcnamara, John" , "Tahhan, Maryam" Message-ID: <20170522091323.GO1758@6wind.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> <2601191342CEEE43887BDE71AB9772583FAF803F@IRSMSX109.ger.corp.intel.com> <20170519091127.GY14914@bidouze.vm.6wind.com> <3128026.nHak02edMh@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3128026.nHak02edMh@xps> Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify 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: Mon, 22 May 2017 09:13:31 -0000 On Fri, May 19, 2017 at 12:11:53PM +0200, Thomas Monjalon wrote: > 19/05/2017 11:11, Gaëtan Rivet: > > On Fri, May 19, 2017 at 08:57:01AM +0000, Ananyev, Konstantin wrote: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > >> 18/05/2017 13:33, Ferruh Yigit: > > >> > On 5/17/2017 5:38 PM, Gaëtan Rivet wrote: > > >> > > The other is the expression of flows through a shared syntax. Using > > >> > > flags to propose presets can be simpler, but will probably not be flexible > > >> > > enough. rte_flow_items are a first-class citizen in DPDK and are > > >> > > already a data type that can express flows with flexibility. As > > >> > > mentioned, they are however missing a few elements to fully cover IPFIX > > >> > > meters, but nothing that cannot be added I think. > > >> > > > > >> > > So I was probably not clear enough, but I was thinking about > > >> > > supporting rte_flow_items in rte_flow_classify as the possible key > > >> > > applications would use to configure their measurements. This should not > > >> > > require rte_flow supports from the PMDs they would be using, only > > >> > > rte_flow_item parsing from the rte_flow_classify library. > > >> > > > > >> > > Otherwise, DPDK will probably end up with two competing flow > > >> > > representations. Additionally, it may be interesting for applications > > >> > > to bind these data directly to rte_flow actions once the > > >> > > classification has been analyzed. > > >> > > > >> > Thanks for clarification, I see now what you and Konstantin is proposing. > > >> > > > >> > And yes it makes sense to use rte_flow to define flows in the library, I > > >> > will update the RFC. > > >> > > >> Does it mean that rte_flow.h must be moved from ethdev to this > > >> new flow library? Or will it depend of ethdev? > > > > Even outside of lib/librte_ether, wouldn't rte_flow stay dependent on > > rte_ether? > > > > > > > >Just a thought: probably move rte_flow.h to lib/librte_net? > > >Konstantin > > > > If we are to move rte_flow, why not lib/librte_flow? > > There are 3 different things: > 1/ rte_flow.h for flow description > 2/ rte_flow API in ethdev for HW offloading > 3/ SW flow table (this new lib) > > 2 and 3 will depends on 1. > I think moving rte_flow.h in librte_net is a good idea. If I had to choose, it would be librte_flow over librte_net because rte_flow is not necessarily about matching protocol headers (e.g. you can can match meta properties like physical ports or the fact traffic comes from a specific VF). However, I am not sure a separate library is actually necessary, I think the requirements can be addressed by rte_flow (in its current directory) directly. One assumption is that the COUNT action as currently described by rte_flow satisfies the counters requirements from this proposal, new actions could be added later to return other flow-related properties. In short there is no need to return info from individual packets, only from the flows themselves. If the above is true, then as pointed earlier by Gaetan this proposal can be summarized as a software implementation for rte_flow_query() and related actions. To determine if a packet is part of a given flow in software and update the associated flow counters, it must be parsed and compared against patterns of all existing rte_flow rules until one of them matches. For accurate results, this must be done on all TX/RX traffic. RFCv1 does so by automatically hooking burst functions while RFCv2 does so by expecting the application to call rte_flow_classify_stats_get(). One issue I would like to raise before going on is the CPU cost of doing all this. Parsing all incoming/outgoing traffic without missing any, looking up related flows and updating counters in software seems like a performance killer. Applications will likely request assistance from HW to minimize this cost as much as possible (e.g. using the rte_flow MARK action if COUNT is not supported directly). Assuming a flow is identified by HW, parsing it once again in software with the proposed API to update the related stats seems counterproductive; a hybrid HW/SW solution with the SW part automatically used as a fallback when hardware is not capable enough would be better and easier to use. The topic of software fallbacks for rte_flow was brought up some time ago (can't find the exact thread). The intent was to expose a common set of features between PMDs so that applications do not have to implement their own fallbacks. They would request it on a rule basis by setting a kind of "sw_fallback" bit in flow rule attributes (struct rte_flow_attr). This bit would be checked by PMDs and/or the rte_flow_* wrapper functions after the underlying PMD refuses to validate/create a rule. Basically I think rte_flow_classify could be entirely implemented in rte_flow through this "sw_fallback" approach in order for applications to automatically benefit from HW acceleration when PMDs can handle it. It then makes sense for the underlying implementation to use RX/TX hooks if necessary (as in RFCv1). These hooks would be removed by destroying the related flow rule(s). This would also open the door to a full SW implementation for rte_flow given that once the packet parser is there, most actions can be implemented rather easily (well, that's still a lot of work.) Bottom line is I'm not against a separate SW implementation not tied to a port_id for rte_flow_classify, but I would like to hear the community's thoughts about the above first. -- Adrien Mazarguil 6WIND