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 182C3A054A; Thu, 18 Feb 2021 18:58:49 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3578840040; Thu, 18 Feb 2021 18:58:48 +0100 (CET) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by mails.dpdk.org (Postfix) with ESMTP id 70A0E4003D for ; Thu, 18 Feb 2021 18:58:46 +0100 (CET) Received: by mail-qk1-f169.google.com with SMTP id h8so2960076qkk.6 for ; Thu, 18 Feb 2021 09:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hPYvdcogypwJS+01c4dKq7t5OQwY3Fl/nr8dWu6WFk0=; b=aZOSaF4yOv4+JU6syZNL7F8OyaauxkdxJ2UgxAQfO5qpAT/9oI/sng5sOtfE63ibX4 qcKoypnK1pGkECl80bsPM9mCN/yoAKe3NkODHyHZ/0QDxSJcLiK+EKiGBDc+H92wu3uO eeKSnvuqsG6YSe8heVHselXKmMpOW2mxR2M54= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hPYvdcogypwJS+01c4dKq7t5OQwY3Fl/nr8dWu6WFk0=; b=duHcmcbTRK7VSWv80zigkWsnC0HkjJYPFYe+8xGvzvoOVqNwNAiVHo6TlZFQtrS3Fi 6qd+NoDFI9/zyY/EmwaBz9zd1+6Yc9IBxFawdxb8tMgXJzhjJMTL21CLhwiCHq0yR3TJ QX8S98Nhuw7aisQk1CGhi7/ZpzX44mSUm3/kIBUaXRYPC5SYT7LhAyyNkpetXdJkvo28 3y3UazfaP9YQv4Qr3j79aY8yG+QAlaxuSsHdRjn9/5gFmXAl9ZjWbMnRFlZ/MtTnJGCU f003htq+fe6JiC0zNIA6W6zC5/CT0D9XDx6u5ybIELZlDQNWn3ZQnWkO8XvxHdJWleAn TwZw== X-Gm-Message-State: AOAM530dxOGP+7shjWEuj67qpFNrIJrCBtvksazjkh+10dgfOs1BZhvB QbOtA+/UUxIz+uYzvAla55SurNFlUgYEHZrVpIHx5g== X-Google-Smtp-Source: ABdhPJyAADZxnudDCXEEVlJ9DIS6BquUoa98kzm92eG/FzNJgakwQTlz3D1bqBawq15YEJHmYTYFqfgRer78nUlOtgU= X-Received: by 2002:a37:446:: with SMTP id 67mr5398810qke.409.1613671125488; Thu, 18 Feb 2021 09:58:45 -0800 (PST) MIME-Version: 1.0 References: <1612694777-31505-1-git-send-email-asafp@nvidia.com> <6c467b94-8a0e-91b3-4c4f-576730a7ed33@intel.com> <24451137.kzuPNkPQvE@thomas> In-Reply-To: <24451137.kzuPNkPQvE@thomas> From: Ajit Khaparde Date: Thu, 18 Feb 2021 09:58:29 -0800 Message-ID: To: Thomas Monjalon Cc: Ferruh Yigit , Asaf Penso , "dev@dpdk.org" , "Gal Cohen (ProdM)" , Andrew Rybchenko , Jerin Jacob Kollanukkaran Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000004089f405bba01629" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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" --0000000000004089f405bba01629 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 17, 2021 at 2:49 AM Thomas Monjalon wrote: > 17/02/2021 11:37, Ferruh Yigit: > > On 2/17/2021 5:57 AM, Asaf Penso wrote: > > > From: Ferruh Yigit > > >> 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. > > I think in general we are missing a big disclaimer > on top of this overview page: > Each feature may have some hardware limitations. > > Then there is a need, both for application developers and end-users, > to know which feature can be supported by a PMD, > or which PMD can support a feature. > Yes there are complex limitations with hardware offloads in general. > Yes it would be nice to report some tested capabilities with a CI. > But it does not mean we should not try to document it in my opinion. > +1 to all of these. A document like this will help give an idea on what is possible with the PMD without looking at the code. Beyond that, the user can check with the vendor/developer for specific details if needed. --0000000000004089f405bba01629--