From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id C37D337B4 for ; Mon, 22 Aug 2016 20:20:32 +0200 (CEST) Received: by mail-pa0-f52.google.com with SMTP id pp5so39817561pac.3 for ; Mon, 22 Aug 2016 11:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=kKe4ueCEskwx8EkglkJ3l+AR9/OozMJiAb/FOLDheWQ=; b=N6K0WczeF1S/2LBNBg9s9C39Jbla1uV9kkPMr5iJsFcaRdkjdqRsX12mv6q4oOm822 3+8fUE6yc4dgYNu4coeli0KQbgpnX52VIDE1mjK4mJ/FDp9zLtXq553OTn+V0iLM5zrN U+YCDuFUqDcN6StpcbConxChZZP0g4ryIBQhRElBSBM1XAS6jhd7zPNPxXJxUhOkcpX3 XH6/ucIfseuwM9MO3Pp4I+YfDayGKO5yDOPPFMa5JcsUd6XpZ+Dp7ZJfksOV7lIEgyrL 2iHA+Ikmo4k/NFVGY7Ha31NxWEagIIvNxq1kM9SyyebG9BvIFFSq9p+GpJ1j22hN/5Vc gL3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kKe4ueCEskwx8EkglkJ3l+AR9/OozMJiAb/FOLDheWQ=; b=Bo0voNjDxPwNQpvH6jv+rEv7OznJZ1BBtNiOwG8EbmhyjhF4yoW5OU+RU8GgK9ZNhi lrO8mIbO/PMh1DulOyISm1YtiFCu3Gai9GnKLuDaTR0zXXyk9ZCipQBrH7ox7w2ZnpU4 TKfPSkzNRzYqx3T3okeYKNrAW0JwL6dbDc0EXB7UXKk44CAtYtTlxp8x1YRMTZtnyfVc HLX60T0hH73j8gyf/YPYRk2htTYeeZRvGD17p64co/OzZ5IFfUqunhDAHZxo2XvqvpSH tf1AgxNSMjkWaMGV9njZ27klCdlctDMi2K+jdfX3tOEiMOw3uVThFjPmqHSlFApBLjHI Et8Q== X-Gm-Message-State: AEkooutpEeY4baTEIV1+lFb5aDFF1kMARyNUqrDC8YjCotoV0f2D198OPMuM9fZ6+d6rQw== X-Received: by 10.66.139.227 with SMTP id rb3mr44466417pab.26.1471890031694; Mon, 22 Aug 2016 11:20:31 -0700 (PDT) Received: from [192.168.1.5] ([72.168.144.203]) by smtp.googlemail.com with ESMTPSA id g24sm28852264pfk.56.2016.08.22.11.20.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Aug 2016 11:20:30 -0700 (PDT) To: Adrien Mazarguil , dev@dpdk.org References: <20160705181646.GO7621@6wind.com> <31d00ae664a3aba26a2c703f53bcc6a5b11502b7.1471632644.git.adrien.mazarguil@6wind.com> From: John Fastabend Message-ID: <57BB4260.5080609@gmail.com> Date: Mon, 22 Aug 2016 11:20:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <31d00ae664a3aba26a2c703f53bcc6a5b11502b7.1471632644.git.adrien.mazarguil@6wind.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC v2] ethdev: introduce generic flow API 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: Mon, 22 Aug 2016 18:20:33 -0000 On 16-08-19 12:32 PM, Adrien Mazarguil wrote: > This new API supersedes all the legacy filter types described in > rte_eth_ctrl.h. It is slightly higher level and as a result relies more on > PMDs to process and validate flow rules. > > It has the following benefits: > > - A unified API is easier to program for, applications do not have to be > written for a specific filter type which may or may not be supported by > the underlying device. > > - The behavior of a flow rule is the same regardless of the underlying > device, applications do not need to be aware of hardware quirks. > > - Extensible by design, API/ABI breakage should rarely occur if at all. > > - Documentation is self-standing, no need to look up elsewhere. > > The existing filter types will be deprecated and removed in the near > future. > > Note that it is not complete yet. This commit only provides the header > file. The specification is provided separately, see below. > > HTML version: > https://rawgit.com/6WIND/rte_flow/master/rte_flow.html > > PDF version: > https://rawgit.com/6WIND/rte_flow/master/rte_flow.pdf > > Git tree: > https://github.com/6WIND/rte_flow > > Signed-off-by: Adrien Mazarguil > --- Hi Adrien, [...] > + > +/** > + * Flow rule attributes. > + * > + * Priorities are set on two levels: per group and per rule within groups. > + * > + * Lower values denote higher priority, the highest priority for both levels > + * is 0, so that a rule with priority 0 in group 8 is always matched after a > + * rule with priority 8 in group 0. > + * > + * Although optional, applications are encouraged to group similar rules as > + * much as possible to fully take advantage of hardware capabilities > + * (e.g. optimized matching) and work around limitations (e.g. a single > + * pattern type possibly allowed in a given group). > + * > + * Group and priority levels are arbitrary and up to the application, they > + * do not need to be contiguous nor start from 0, however the maximum number > + * varies between devices and may be affected by existing flow rules. > + * Another pattern that I just want to note, I think it can be covered is to map rules between groups. The idea is if we build a "tunnel-endpoint" group based on a rule in the tunnel-endpoint we might map this onto a "switch" group. In this case the "switch" group match should depend on a rule in the "tunnel-endpoint" group. Meaning the TEP select the switch. I believe this can be done with a metadata action. My idea is to create a rule in "tunnel-endpoint" group that has a match based on TEP address and then an action "send-to-switch group" + "metadata set 0x1234". Then in the "switch group" add a match "metadata eq 0x1234" this allows linking groups together. It certainly doesn't all need to be in the first iteration of this series but do you think this is reasonable as a TODO/future extension. And if we standardize around group-ids the semantics should be consistent for at least the set of NICs that support tunnel endpoint and multiple switches. Any thoughts? .John