From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f174.google.com (mail-wj0-f174.google.com [209.85.210.174]) by dpdk.org (Postfix) with ESMTP id 7BA1210C96 for ; Wed, 21 Dec 2016 17:19:18 +0100 (CET) Received: by mail-wj0-f174.google.com with SMTP id v7so207061636wjy.2 for ; Wed, 21 Dec 2016 08:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=1XoKIVj5Pnh7j+O1ePXsLRpbpC26gfFgUMh1ljWqbyw=; b=TbrAzR3d2V19L8BoC4hQaLao4jSsLMPQm+wZ2pVXg2sET4GBFXZtKmnvoPUE4NOLO9 Qwn4ZsTLGM+JAcl1bbKEljo7EY9aOj3Bp+HPTBL5xMrEB13k4/heIuxZS03vkcVZTNBP JPhc5seIPDacxM5wWvY44T2SmAXdUrWpiTvZjBwQFFmJmvjdfAdGdz0WCDJwpoU0Ds8v fmPJ9cefRIY8dlyc7K/glmcEpljGsI2DZS/5s8a11rCaeNkmn6RX2pDslfTh9rAeTrVf 0Hp3ANvo1tVtXrxhGGMdu/8y0cD3E2dqaY8WAz0EJhZ9HmM89BKHOARHqBNqjT9+tS+s UF8A== 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:user-agent; bh=1XoKIVj5Pnh7j+O1ePXsLRpbpC26gfFgUMh1ljWqbyw=; b=cswoYY3T8FXz+fz7XevBiDIh9rxM3AtSs3HIZT7e/fkUbqukXY758mOVmj30EXi54B rJG2jc4+GcL2LIk1MDJfj3ryg++BU21lrJjJ8t5ZffVgA/ak+dj5s+Ecy8YJjB2i8O5S HawofsrDrmYYFJsyl1a34NlSTWYwkSnVGkdZsTIVDGBGN/71SZK8+j2/S1lAFWZXZmAU TfzV48spG9/FNi2oOSnv+8t0qyhDi/OqEjAPH8pk9zxz0Okc6c6znjau3ZrEZ0EfsfD5 bVGCyfwfe+k5i9kFt6UA8ZOUJEOtZRRSgI8ZcRSQ8DwSO8tRW5Y1+5j6RErvy8JbnOle jW5A== X-Gm-Message-State: AIkVDXIA8se3k6f8lJj4U9Do52mdPpoYSe7jhiScS897mNAhp9f5xyNm9nZ3y3o57V6LL8SK X-Received: by 10.194.134.66 with SMTP id pi2mr4969540wjb.61.1482337158101; Wed, 21 Dec 2016 08:19:18 -0800 (PST) Received: from penelope.horms.nl (52D9BC73.cm-11-1c.dynamic.ziggo.nl. [82.217.188.115]) by smtp.gmail.com with ESMTPSA id jz1sm5806703wjc.38.2016.12.21.08.19.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 08:19:16 -0800 (PST) Date: Wed, 21 Dec 2016 17:19:16 +0100 From: Simon Horman To: Adrien Mazarguil Cc: dev@dpdk.org Message-ID: <20161221161914.GA14515@penelope.horms.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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, 21 Dec 2016 16:19:18 -0000 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 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? 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. * 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. * 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. With the above questions in mind I am curious to know what use-cases the proposal is targeted at.