From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f179.google.com (mail-wj0-f179.google.com [209.85.210.179]) by dpdk.org (Postfix) with ESMTP id 764AF2C01 for ; Wed, 4 Jan 2017 19:12:27 +0100 (CET) Received: by mail-wj0-f179.google.com with SMTP id tq7so238571722wjb.0 for ; Wed, 04 Jan 2017 10:12:27 -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=IXro9M1Zaj/G3ioekSN3a25hhZzCAGLNKCEVD/aJuMA=; b=QYJLw+6WK6YaalchsOK17O6f3HXyqBnLkgtgHQpFQ9fkAvn+mXY44LBKJiAWpD1Yzw uTD/522ulJW0UbtuvKjQGWtO5zhay8HJP3zKSkAoh8ypfrsJkuVZ+A7suHZsC2QNp+sE SZkrKMoDRbQ5qzhfNxT3c8R42IlYrRMWW4zMHI7vdWY5DBZg9/T1ICzBUOdQXKg/sUqq Vbe0+WikqlcsGRBsfxIP0FB3zmy9eaTHWSAh+yUWbYvTMc5Gd3KTMYyf3euzxdUnVwmf +FNaYDGMx9e8KHx2q2vExkIB+jtmokSumbijy2rHq2z/40EwVbG6QI3dgE9ouLDeuH4G EpVQ== 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:in-reply-to; bh=IXro9M1Zaj/G3ioekSN3a25hhZzCAGLNKCEVD/aJuMA=; b=cyb0STw7KEUb/pZw5GMkuYAetquwq4Uufv9MMOIlE4Nx4ytNNxeR9U3Z7gGr+XEbOy 6MzB9NPWg5hP3BzzKyxBWsMsQ5R8mNPZAQgIj8TD8soinE8tq+ZVK9UGu91nLQaszBNf bWX2MrE0nFpMPXNbrhXW4WrAe/i6zGTC1/0GO1e4YDvreeo3+JsTIzeCwpxzqy4GPHKs h10avDInZvgqjAfVjVMmv/0aq11Z+Stl1AGefew0XyJAbIWYo84iOaRxUGweFLScBQNp YQVKJxzsWpRw+DNAgKWVbU5NdYzPi1vIhoyhiXKQu1C3lUjYEtWeHw2x437iJTbTzhn0 FUVQ== X-Gm-Message-State: AIkVDXJMdGXWiqKUiv6f3jkCYv6LV8j89FSTxzYzG/4e8Rx9FNC/GgYXftet8/0b0V2pfLT4 X-Received: by 10.194.90.83 with SMTP id bu19mr58155885wjb.68.1483553547029; Wed, 04 Jan 2017 10:12:27 -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 uz7sm5013387wjc.11.2017.01.04.10.12.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 10:12:26 -0800 (PST) Date: Wed, 4 Jan 2017 19:12:19 +0100 From: Adrien Mazarguil To: Simon Horman Cc: dev@dpdk.org Message-ID: <20170104181219.GH12822@6wind.com> References: <20161221161914.GA14515@penelope.horms.nl> <20161222124804.GD10340@6wind.com> <20170104095347.GA24762@penelope.horms.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170104095347.GA24762@penelope.horms.nl> Subject: Re: [dpdk-dev] [PATCH v2 00/25] Generic flow API (rte_flow) 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: Wed, 04 Jan 2017 18:12:27 -0000 On Wed, Jan 04, 2017 at 10:53:50AM +0100, Simon Horman wrote: > On Thu, Dec 22, 2016 at 01:48:04PM +0100, Adrien Mazarguil wrote: > > On Wed, Dec 21, 2016 at 05:19:16PM +0100, Simon Horman wrote: > > > On Fri, Dec 16, 2016 at 05:24:57PM +0100, Adrien Mazarguil wrote: [...] > > > I would like to ask some high level questions on the proposal. > > > I apologise in advance if any of these questions are based on a > > > misunderstanding on my part. > > > > > > * I am wondering about provisions for actions to modify packet data or > > > metadata. I do see support for marking packets. Is the implication of > > > this that the main focus is to provide a mechanism for classification > > > with the assumption that any actions - other than drop and variants of > > > output - would be performed elsewhere? > > > > I'm not sure to understand what you mean by "elsewhere" here. Packet marking > > as currently defined is a purely ingress action, i.e. HW matches some packet > > and returns a user-defined tag in related meta-data that the PMD copies to > > the appropriate mbuf structure field before returning it to the application. > > By elsewhere I meant in the application, sorry for being unclear. OK, then a high level definition would be that PMDs perform all actions part of a flow rule, and applications are left to handle what they did not explicitly request to be offloaded. > > There is provision for egress rules and I wrote down a few ideas describing > > how they could be useful (as above), however they remain to be defined. > > > > > If so I would observe that this seems somewhat limiting in the case of > > > hardware that can perform a richer set of actions. And seems particularly > > > limiting on egress as there doesn't seem anywhere else that other actions > > > could be performed after classification is performed by this API. > > > > A single flow rule may contain any number of distinct actions. For egress, > > it means you could wrap matching packets in VLAN and VXLAN at once. > > > > If you wanted to perform the same action twice on matching packets, you'd > > have to provide two rules with defined priorities and use a non-terminating > > action for the first one: > > > > - Rule with priority 0: match UDP -> add VLAN 42, passthrough > > - Rule with priority 1: match UDP -> add VLAN 64, terminating > > > > This is how automatic QinQ would be defined for outgoing UDP packets. > > Ok understood. I have two follow-up questions: > > 1. Is the "add VLAN" action included at this time, I was not able to find it It has not been defined yet. All egress offload actions remain to be defined. > 2. Was consideration given to allowing multiple actions in a single rule? > I see there would be some advantage to that if classification is > expensive. Yes, it is supported as described in the documentation (now available on-line since the series has been applied [3]). What is not supported however is requesting the same action to be performed multiple times in a single flow rule, because order is not guaranteed by design. Actions may all happen simultaneously. This scenario can be handled with multiple rules using priorities as in my QinQ example above, or through a new action performing several things at once in a defined order (e.g. a single "QinQ" action). > > > * I am curious to know what considerations have been given to supporting support for tunnelling (encapsulation and decapsulation of e.g. VXLAN), > > > tagging (pushing and popping e.g. VLANs), and labels (pushing or popping > > > e.g. MPLS). > > > > > > Such features seem would useful for application of this work in a variety > > > of situations including overlay networks and VNFs. > > > > This is also what I had in mind and we'd only have to define specific > > ingress/egress actions for these. Currently rte_flow only implements a basic > > set of existing features from the legacy filtering framework, but is meant > > to be extended. > > Thanks. I think that answers most of my questions: what I see as missing > in terms of actions can be added. > > > > * I am wondering if any thought has gone into supporting matching on the > > > n-th instance of a field that may appear more than once: e.g. VLAN tag. > > > > Sure, please see the latest documentation [1] and testpmd examples [2]. > > Pattern items being stacked in the same order as protocol layers, maching > > specific QinQ traffic and redirecting it to some queue could be expressed > > with something like: > > > > testpmd> flow create 0 ingress pattern eth / vlan vid is 64 / vlan vid is 42 / end > > actions queue 6 / end > > > > Such a rule is translated as-is to rte_flow pattern items and action > > structures. > > Thanks, I will look over that. > > > > With the above questions in mind I am curious to know what use-cases > > > the proposal is targeted at. > > > > Well, it should be easier to answer if you have a specific use-case in mind > > you would like to support but that cannot be expressed with the API as > > defined in [1], in which case please share it with the community. > > A use-case would be implementing OvS DPIF flow offload using this API. OK, OVS has been mentioned several times in this thread and my understanding is that rte_flow seems to accommodate most of its needs according to people familiar with it. Perhaps ML archives can answer the remaining questions you may have about combining rte_flow with OVS. > > [1] http://dpdk.org/ml/archives/dev/2016-December/052954.html > > [2] http://dpdk.org/ml/archives/dev/2016-December/052975.html [3] http://dpdk.org/doc/guides/prog_guide/rte_flow.html -- Adrien Mazarguil 6WIND