From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id EF48D2C00 for ; Wed, 24 Feb 2016 23:19:33 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id g62so3043636wme.1 for ; Wed, 24 Feb 2016 14:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=TG88prcBn4qx7CJ8wtN++dQNwWeYuR7lawKpYFzhNJM=; b=Oc2rARoPTFOQTueWuUSF0SDclOneY3Q3FFEnJ3ovXDRL6by6SpONz47nzTJgjtJoMe CdbRUxUkQxpdTFAczuwTp4HxilEQDl7bZa6yqgpHb2bk4/Q+nuQn75Vn4T7PS/5RbXaB pNk4HVeGpIH0U/7qBh8IZaOeKoUrGezJ5vQQU8zkH5fW+Kjl1SsYuR+XEDOVgjHGHF5l khaFJQ1DcLtfnjdgj/EtQl/qZCbsOu4rPxgFpcJ7oLDNdpo4KGJa/iKIbf+wETFVqXsz xSozJUwqXGY4O5owRUcGD3URhnjsYec+l0taRN7InMzyeddPSM1N7AH+4HvdM3H/X4Ex W74g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=TG88prcBn4qx7CJ8wtN++dQNwWeYuR7lawKpYFzhNJM=; b=Ex+Fv7hcGgil5I/9C9smdrsqSwaqnaptxebZT34rGQvT2UAeCZd9xFuGdt18sz7Hk1 JaLAOIUewv8P8BMgFUVj/KGSztwJ0Z2T0W2sD0GuPz1rd5ZuoGeeDaQ6Ul7mVVMhWg4c 8yfNUO6NqWr681xnqrIl+lAHmYGKENwmTUanlefpI+CGE4Je8Z9eRvJ8XtRke/9smF/W CzbvplLgI01FEM/0D1anf4vE2tab41YfkfLjH+ELp42FZa7O9Z84YP00WycvJUwWGSol eOc/rfWzDb03pztovljDKL5BFtGQjfNKdSBoyosoj0LxpFPtrXmx/7J4Rpej32KEjUh+ uFuQ== X-Gm-Message-State: AG10YOTeLHMhUjT/hM9WVihRMKfeKYVi1ZCrkehyX7NoFX490n5vRQ233xt86uVw4XzyDDEp X-Received: by 10.194.47.237 with SMTP id g13mr41728565wjn.142.1456352373850; Wed, 24 Feb 2016 14:19:33 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id j18sm249657wmd.2.2016.02.24.14.19.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 14:19:32 -0800 (PST) From: Thomas Monjalon To: Rahul Lakkireddy Date: Wed, 24 Feb 2016 23:17:58 +0100 Message-ID: <3102616.xnBgmsEaQs@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160224184006.GB8856@chelsio.com> References: <13893420.AuWBYNZ43L@xps13> <20160224184006.GB8856@chelsio.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, Kumar A S , Nirranjan Kirubaharan Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir 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, 24 Feb 2016 22:19:34 -0000 Caution: I truly respect the work done by Chelsio on DPDK. And I'm sure you can help to build a good filtering API, which was mainly designed with Intel needs in mind because it was difficult to have opinions of other vendors some time ago. That's why it's a chance to have new needs and it would be a shame to let it go through a vendor specific backdoor. 2016-02-25 00:10, Rahul Lakkireddy: > Hi Thomas, > > On Wednesday, February 02/24/16, 2016 at 07:02:42 -0800, Thomas Monjalon wrote: > > 2016-02-24 14:43, Bruce Richardson: > > > On Wed, Feb 03, 2016 at 02:02:22PM +0530, Rahul Lakkireddy wrote: > > > > Add a new raw packet flow that allows specifying generic flow input. > > > > > > > > Add the ability to provide masks for fields in flow to allow range of > > > > values. > > > > > > > > Add a new behavior switch. > > > > > > > > Add the ability to provide behavior arguments to allow rewriting matched > > > > fields with new values. Ex: allows to provide new ip and port addresses > > > > to rewrite the fields of packets matching a filter rule before NAT'ing. > > > > > > > Thomas, any comments as ethdev maintainer? > > > > Yes, some comments. > > First, there are several different changes in the same patch. It must be split. > > Should each structure change be split into a separate patch? A patch = a feature. The switch action and the flow rule are different things. > > Then I don't understand at all the raw flow filter. What is a raw flow? > > How behavior_arg must be used? > > This was discussed with Jingjing at > > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/31471 Thanks, I missed it. > A raw flow provides a generic way for vendors to add their vendor > specific input flow. Please, "generic" and "vendor specific" in the same sentence. It's obviously wrong. > In our case, it is possible to match several flows > in a single rule. For example, it's possible to set an ethernet, vlan, > ip and tcp/udp flows all in a single rule. We can specify all of these > flows in a single raw input flow, which can then be passed to cxgbe flow > director to set the corresponding filter. I feel we need to define what is an API. If the application wants to call something specific to the NIC, why using the ethdev API? You just have to include cxgbe.h. > On similar lines, behavior_arg provides a generic way to pass extra > action arguments for matched flows. For example, in our case, to > perform NAT, the new src/dst ip and src/dst port addresses to be > re-written for a matched rule can be passed in behavior_arg. Yes a kind of void* to give what you want to the driver without the convenience of a documented function. I know the support of filters among NICs is really heterogeneous. And the DPDK API are not yet generic enough. But please do not give up! If the filtering API can be improved to support your cases, please do it.