From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C7960A059B; Fri, 10 Apr 2020 11:20:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1F5A31D414; Fri, 10 Apr 2020 11:20:54 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id A0D551D412 for ; Fri, 10 Apr 2020 11:20:52 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DDD345C021F; Fri, 10 Apr 2020 05:20:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 10 Apr 2020 05:20:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=cWqpUtQVnxCBZsUPnipEb2pdDD2a/O9J/csH2TC0vbE=; b=RE2wa42vxF1Q T5+Nu51olPFQcC2XsY2v7FhEfyHzFlA9ytWk9X7fePk3jGecI5nvynqpQEYJwKjy 9Qhyzg8fgqhzO405lCHi2duyvRAIuMLLV4uoDnpDwsgGGkZQZ9SAW7G8BtXaUYN/ 4eCyjXaeBFn7NtoHAw6j4mN2PQB9wVo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=cWqpUtQVnxCBZsUPnipEb2pdDD2a/O9J/csH2TC0v bE=; b=aIrxm2Lslk1O/1/061vmThMG4IhSYJb9GDsLieE5VJiifnZCtxpz7RzWJ zOJAKw49VtjcorSyp7AwgqBnXpzuf3mZbj7TrxvmAoJk5Ct93zlWSC8zRkOAH/X4 k+Vgn4gbDcfreuV/Z+SXCT7lHUnRmdK2eO7xLxdkftMvfNeVf8+MfIaiQP6Z0hXJ KySxE4jchAKZ4e3pkyaY4gApA4t9F56WJmGckqcc7SeRbMRF3S33EH2D/gpSzWiI cvJV2AbCA3Vcs2BEPF+8GJ4pv5Gy6J5B0mlP/3t0XKbPbykerlxKLpzWvE9YUFce Yl8vJa3MkB2iVckwkX7PmePHmywNQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvddvgdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E1773280060; Fri, 10 Apr 2020 05:20:49 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Ferruh Yigit , John McNamara , Marko Kovacevic , dpdk-dev , Andrew Rybchenko , Adrien Mazarguil , Ajit Khaparde , Jerin Jacob , Ori Kam Date: Fri, 10 Apr 2020 11:20:48 +0200 Message-ID: <3196060.usfYGdeWWP@thomas> In-Reply-To: References: <20191025125118.47189-1-ferruh.yigit@intel.com> <1689523.vCJZsxu672@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 2/2] doc: remove flow API from the feature list 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 10/04/2020 11:04, Jerin Jacob: > On Fri, Apr 10, 2020 at 2:26 PM Thomas Monjalon wrote: > > 10/04/2020 10:44, Ferruh Yigit: > > > On 10/25/2019 2:39 PM, Jerin Jacob wrote: > > > > On Fri, Oct 25, 2019 at 6:56 PM Thomas Monjalon wrote: > > > >> > > > >> 25/10/2019 14:51, Ferruh Yigit: > > > >>> "Flow API" is a method/API to implement various filtering features, on > > > >>> its own it doesn't give much context on what features are provided. And > > > >>> it is not really a feature, so doesn't fit into feature table. > > > >>> > > > >>> Also since other filtering related APIs, 'filter_ctrl', has been > > > >>> deprecated, flow API is the only supported way in the DPDK to implement > > > >>> filtering options, if related filter options announced by PMDs, listing > > > >>> "Flow API" as implemented is redundant information. > > > >> > > > >> I fully agree with this explanation. > > > >> rte_flow is the only supported API for flow offloads. > > > >> That's why we must remove the legacy API. > > > >> > > > >>> Signed-off-by: Ferruh Yigit > > > >>> --- > > > >>> --- a/doc/guides/nics/features/default.ini > > > >>> +++ b/doc/guides/nics/features/default.ini > > > >>> -Flow API = > > > >> > > > >> Acked-by: Thomas Monjalon > > > > > > > > # Need to remove "Flow API" from doc/guides/nics/features.rst > > > > > > +1 > > > > > > > # Need to remove refference of "Flow API" from "doc/guides/nics/*" as well. > > > > > > "Flow API" is the implementation of the filtering, it may exist in the nic > > > documentation, only it is not a feature on itself. I will scan the docs for usage. > > > > > > > > > > > Not specific to this patch, > > > > Probably we need to add a new matrix to enumerate PATTERN and ACTIONS > > > > supported by each PMD as a rte_flow feature matrix. > > > > That some else can take it up if everyone agrees the semantics. > > > > > > > > > > +1, there needs a way to figure out which filtering is supported by a > > > device/driver. It is not documented and it is very hard to got it from the code. > > > > > > Not sure if a new matrix is the good way to go, but I agree we need some way to > > > clarify it. > > > > I think we should split the matrix. > > Adding a new matrix for flow offloads looks the way to go. > > I suggest 3 matrices: > > - port-level features > > - queue-level features > > - flow-level features > > Not sure what will be the details in "flow-level features". > > IMO, We need to have a separate matrix for subdomain features for > rte_flow, rte_tm, rte_mtr, etc which part of ethdev. > For instance, rte_flow features can be translated into a matrix of > supported PATTERN and ACTIONS. Yes I'm also fine with this proposal.