From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 988EBA054D; Wed, 17 Feb 2021 11:38:02 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1E11A40690; Wed, 17 Feb 2021 11:38:02 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 8AE814067A for ; Wed, 17 Feb 2021 11:38:00 +0100 (CET) IronPort-SDR: F7Fp8JDrkMjmPeAxyIbqpBRargoMORu7177D1KhQ2URIlRnO+0nEfBPhW+GIaHGYOr/EE0Wg6e bxCe0UmFluXg== X-IronPort-AV: E=McAfee;i="6000,8403,9897"; a="179652019" X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="179652019" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 02:37:58 -0800 IronPort-SDR: 0wW+/ltJT/jkDclb8X2BBVXneN80U4JjI1aVeiW/odGm5VGNP9FBkSfQT287e6jEAO513dCyLz /wegjX0BgYCg== X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="399907501" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.4.215]) ([10.252.4.215]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 02:37:56 -0800 To: Asaf Penso , "dev@dpdk.org" Cc: NBU-Contact-Thomas Monjalon , "Gal Cohen (ProdM)" , Andrew Rybchenko References: <1612694777-31505-1-git-send-email-asafp@nvidia.com> <1612695128-31878-1-git-send-email-asafp@nvidia.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <6c467b94-8a0e-91b3-4c4f-576730a7ed33@intel.com> Date: Wed, 17 Feb 2021 10:37:52 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4] doc: add new tables for rte flow items and actions support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On 2/17/2021 5:57 AM, Asaf Penso wrote: > Hello Ferruh, thanks for the reply and please see my below comments. > > Regards, > Asaf Penso > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Tuesday, February 16, 2021 3:14 PM >> To: Asaf Penso ; dev@dpdk.org >> Cc: NBU-Contact-Thomas Monjalon ; Andrew >> Rybchenko >> Subject: Re: [dpdk-dev] [PATCH v4] doc: add new tables for rte flow items and >> actions support >> >> On 2/7/2021 10:52 AM, Asaf Penso wrote: >>> In http://doc.dpdk.org/guides/nics/overview.html, table 1.1 lists all >>> supported features. >>> It has a single line for "Flow API" that refers to rte_flow support. >>> rte_flow is composed of many items and actions that are not expressed >>> in this single line. >>> >>> The following new tables are suggested: >>> 1. rte_flow items >>> 2. rte_flow actions >>> >> >> Hi Asaf, >> >> I understand the intention, but I am not sure about this. >> >> The Flow API does not provide a capability or feature list in the API level, by >> design, because it is very hard to do it correct, but this patch tries to do it in the >> documentation level. >> >> This will be missing lots of details, the flow items and actions documented as >> supported may and may not be supported based on the details. >> > > Which missing details are you referring to? All flow items and all actions are listed. > Patterns are complex, any rule can be valid or invalid based on provided pattern values (details), also any rule can be valid or invalid based on previous rules or configuration. In practice this information is much more useful if it is provided by API, but we are not able to do it because of its complex nature, it should be same level of complexity to provide this information by documentation. >> It will be very hard to read this table (when it becomes full), also will be very hard >> to maintain. > > As part of any documentation change in rte_flow the developer would also need to update this table. > Why would it be very hard to maintain? > Ahh, that sound so simple when you say like this :) In practice even keeping feature list requiring lots of effort, developers are missing/neglecting/ignoring updating documentation when updating the code. And for this case is partially correct table a useful information? If this is not completely correct people won't rely on it and it will become just useless. So this feature should come with an automated way to detect if a rule supported but not documented, or even better this table should be generated from code automatically. >> >> >> Let me start with a question, who do you think will be your consumer? >> Who will benefit from this table and how? > > We get a lot of questions from users regarding rte_flow support and we do not have a single place with proper documentation. > I can ask the same about the overall feature table, right? There is a value to document the support. > Let's discuss the feature table separately, I think that is a valid question. For the rte_flow, who is asking questions? End user, or application developer? So is this intended to be a marketing documentation or technical documentation? And what is the nature of the questions, if it is related to the rte_flow, there is already a proper documentation for it: https://doc.dpdk.org/guides/prog_guide/rte_flow.html If this question is if any specific rule supported by a specific PMD, right now only valid way to say this that I am aware of is, run 'rte_flow_validate()' and see. Not sure if we can document this properly. >> >> >>> Also, since each table needs a new section in the pmd ini >>> file that might not be relevant for all pmds, the print >>> error message for missing section in conf.py is removed. >>> >>> Signed-off-by: Asaf Penso >> >> <...>