From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 831362C5 for ; Fri, 19 May 2017 11:11:34 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id d127so79607392wmf.0 for ; Fri, 19 May 2017 02:11:34 -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=CkeM+vlBmbZZChpB3b7+mAJpzcL50j7lqPtelwAcqPE=; b=G41VSbtfXb8v3BlJ4J0SYcGPncYAloKJKtnKilSgWb32OVPZP+1oknbVqZHwBdpKb2 rgz2BxmFgF6ZSBwTPXX+6+ppkSq2vj+UYvmgSaSNguqcKkaUhVmxqlPvX8s4CS8Pi7re eTcHjADvjp81pS8wGF2yFScdvgjbp68P0FnE1+1f25cQFAl7CSphAn7/soclLqq830Xe zcV9dErel5yd6c+giWS4PKn+mR2UJTdBWo8hcpCxoIrBKsD+LxwK+KQ7nn9DPKP/zZam gcd0Lfq3UrkTWdgrwT9pxI8199ubXy7Ytll/QdvvL//07lDsnSVgRq04CKzMDMCvNZDJ 6uOg== 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=CkeM+vlBmbZZChpB3b7+mAJpzcL50j7lqPtelwAcqPE=; b=bYMPiv5vRzWZ7jMJCQPY7h+1FMOXx6UT35Pah6eTgcvBJXZ2X1sGj8ULEyI+V5Kgc5 4R3hiRnNStuT3+ycm7Mp9JkyUo+aG78mVOkN2H2Cq3YAulqQ/BLlE0EmX2yvnYjVm4lo 6EDdMxKKMcKl3Lhua8mB5/BmM5eBdPf+xstoEC7NdR2i2ErJnaVb6KnJUCaOC8rDHsvJ bswy5sXORCqyjiqhQg19ju1ANqRXRLWkafUO0udcUSFByzqtXmcftY40454IUaELSAdz JyYNiXgwhiPIoBb9Uil+9lGZzZ5DiGkuzGZVaVqURuB6zDEXd0VIknEaqMwyJNrS2llx 6lHg== X-Gm-Message-State: AODbwcDZYSVH/uySffiyr+arBdITKq3fTWWao4Hm9tZ2741z+TW16Z6q oysiq3gh375lm0Ci X-Received: by 10.28.84.67 with SMTP id p3mr5278098wmi.40.1495185093959; Fri, 19 May 2017 02:11:33 -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 b93sm2605173wrd.29.2017.05.19.02.11.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 May 2017 02:11:33 -0700 (PDT) Date: Fri, 19 May 2017 11:11:27 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "Yigit, Ferruh" , "dev@dpdk.org" , "Mcnamara, John" , "Tahhan, Maryam" , "adrien.mazarguil@6wind.com" Message-ID: <20170519091127.GY14914@bidouze.vm.6wind.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> <20170517163848.GQ14914@bidouze.vm.6wind.com> <2028578.MMgbIyi7hy@xps> <2601191342CEEE43887BDE71AB9772583FAF803F@IRSMSX109.ger.corp.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: <2601191342CEEE43887BDE71AB9772583FAF803F@IRSMSX109.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Fri, 19 May 2017 09:11:34 -0000 On Fri, May 19, 2017 at 08:57:01AM +0000, Ananyev, Konstantin wrote: > > >> -----Original Message----- >> From: Thomas Monjalon [mailto:thomas@monjalon.net] >> Sent: Thursday, May 18, 2017 9:32 PM >> To: Yigit, Ferruh >> Cc: dev@dpdk.org; Gaëtan Rivet ; Ananyev, Konstantin ; Mcnamara, John >> ; Tahhan, Maryam ; adrien.mazarguil@6wind.com >> Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library >> >> 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? -- Gaëtan Rivet 6WIND