From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f173.google.com (mail-wj0-f173.google.com [209.85.210.173]) by dpdk.org (Postfix) with ESMTP id 23C9E10D4F for ; Thu, 22 Dec 2016 13:48:14 +0100 (CET) Received: by mail-wj0-f173.google.com with SMTP id ez4so9491679wjd.0 for ; Thu, 22 Dec 2016 04:48:14 -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=8ORaQuIEb/EeTYUxa2U2BfhSOhDhn1S6Pq1cR/n2t9U=; b=puvFTTclFP8YnN6PyPh8WoVIGDUDcaAoZwOLEU5+ecYClUWYhsdMYN9l9MPCK55yCA hwEtLuAYafrFXQ+qM0Tky4FHdapd0ygnOyu9CwsKWq+EuXtY/14dcNRAZ/44M6JanxdB zbVlAWJbTT5TMDGwQTNENsXgAG8qb/u4v+249/Qr1iJKg8WmNinP47U/41a8pNrhFP7c 6x6SUX0K/Ea8rfB/D0Ssjf1c6Wgily+S5dYCpsKFYQFHEDEj3yOwU/uvyIszv+z6YZI8 dC3I6qo67FTPzC0TFje4bXPhA9hohK+dMD3XS4W0I/Dpxw0cm04UFy5wwx5bV13y+TKV EXEA== 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=8ORaQuIEb/EeTYUxa2U2BfhSOhDhn1S6Pq1cR/n2t9U=; b=P/BuuZKnpgkp9gzAM4aC1w0g0hxXg2TAbsz8oyEe/vEuNqx8ic8Qkn9ivHKeYM8fKL qXxWNTkv/XBsd6gcyoWeoGb2+WFYu/JgbEJJpaVYMBcAbkqeuCHxGKzkUlDZvub2AJ9V SvuTvsJnRicvHjBNPCo5ekK+IlWPwxbHPoFHjdnA+AUsqH0mVDCZsDPbKIM2r/RXULby P5k6fwvwFtMFmqxCdLOCkhL5O67Ci8OPCprBK4SWaEtCmrKbR4fi9tvj4huuKFETzmb+ IN/dqZy10S9eC6qJGDYmDNIwV9es7oIGi8hdvivLQ3x9pX7Xxty2vd/z3coq5o7kTBO5 9UOA== X-Gm-Message-State: AIkVDXIhmDYjcki6rHJqd0MZK35Vyh/zW1by/YqVfcttL+F3K/WJ/piB5Gn5XDlCr+9J+UNb X-Received: by 10.194.191.201 with SMTP id ha9mr8913144wjc.205.1482410893779; Thu, 22 Dec 2016 04:48:13 -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 f10sm35419749wjl.28.2016.12.22.04.48.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Dec 2016 04:48:12 -0800 (PST) Date: Thu, 22 Dec 2016 13:48:04 +0100 From: Adrien Mazarguil To: Simon Horman Cc: dev@dpdk.org Message-ID: <20161222124804.GD10340@6wind.com> References: <20161221161914.GA14515@penelope.horms.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161221161914.GA14515@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: Thu, 22 Dec 2016 12:48:14 -0000 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: > > As previously discussed in RFC v1 [1], RFC v2 [2], with changes > > described in [3] (also pasted below), here is the first non-draft series > > for this new API. > > > > Its capabilities are so generic that its name had to be vague, it may be > > called "Generic flow API", "Generic flow interface" (possibly shortened > > as "GFI") to refer to the name of the new filter type, or "rte_flow" from > > the prefix used for its public symbols. I personally favor the latter. > > > > While it is currently meant to supersede existing filter types in order for > > all PMDs to expose a common filtering/classification interface, it may > > eventually evolve to cover the following ideas as well: > > > > - Rx/Tx offloads configuration through automatic offloads for specific > > packets, e.g. performing checksum on TCP packets could be expressed with > > an egress rule with a TCP pattern and a kind of checksum action. > > > > - RSS configuration (already defined actually). Could be global or per rule > > depending on hardware capabilities. > > > > - Switching configuration for devices with many physical ports; rules doing > > both ingress and egress could even be used to completely bypass software > > if supported by hardware. Hi Simon, > Hi Adrien, > > thanks for this valuable work. > > 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. 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. > * 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. > * 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. > 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. [1] http://dpdk.org/ml/archives/dev/2016-December/052954.html [2] http://dpdk.org/ml/archives/dev/2016-December/052975.html -- Adrien Mazarguil 6WIND