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 A0842A3168 for ; Wed, 16 Oct 2019 12:20:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D32CE1E927; Wed, 16 Oct 2019 12:20:44 +0200 (CEST) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by dpdk.org (Postfix) with ESMTP id E38A41E8E0 for ; Wed, 16 Oct 2019 12:20:40 +0200 (CEST) Received: by mail-il1-f194.google.com with SMTP id o16so2035009ilq.7 for ; Wed, 16 Oct 2019 03:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tu8iJ6XGcSE8Uh2no/3Mqu4jsA66PwTufI8wvV8ciGM=; b=JQIMs52K+PFxBq5EXlKiplQNBZgPPqX4naB4rIX5XGBXZZhYD60TQOOCgnRuSReqw+ m3kgNQbFhO5EEi6uO1+h+XnsmRp1rUwSfarwJ5IcD76ddZHKb811qhzOIQ0yr/5gn/9R 86pp53IFiFfbBgWmA1U4WvmFzk6rKvaHmn6U9mHCv7rSoPHxQfHSXdZ7a7TCw+g6HSqJ /+s/CzEWlM4SXgxOTvtenzqWT35wesa0U+jkF410IGbJAWRaVzQ60zQ4DM1umhhExVG4 Pryr6bIslKfZL6SHo7AAM6RiIAVQ2eMCHl2EAWnGIoHiAf2K4KmHuXykc1xmkhLRJnvq ihbw== 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=Tu8iJ6XGcSE8Uh2no/3Mqu4jsA66PwTufI8wvV8ciGM=; b=EqfPjKJFtJFKfOZiv51q7mCXvyLOH7m77H2v/8jOBqqOYSnunI0qBxcCsmmyFaYtDs zAm5pX0S6MOoZlMZNW/n9Eu8OhlQiGa9tOTKsO/vo8ujWFuHTCejj08I2b/UHy8eNWjE i5NOhbsEYhfe/ZKJ8Ezg7s29iuqE7YRIbOv5SJnV6USqqd/knxcEQpUTYN1qKiircFEV twkcG1Ke2BOIzP+L8zq1AiFPUz0V/ZPnsmUxIRr3i2rmDKjx+OKogZTlh0gMV6FWKfaq HWxXAy/d0Sw4GO73LERHJeZ0OXoDK4osx3VIlHb+zK37XGCsUqXnMsA6xpqqf5nmlNDZ 0w7g== X-Gm-Message-State: APjAAAULqGN+qmFXHOWuafBEot79peyv1AK/zvDdm188xM7s7ncvdxTh OxgqdTZRhT9JWvSWqGfVmOiBhGhPKDq8erhlcvo= X-Google-Smtp-Source: APXvYqzmhdXQfnApwpZUrE78GAPbfbQASrq44MJ03OR8j6168+39pnEJOThDMmaAFta4qO4RBU58ZPdV2He0t8LHHJc= X-Received: by 2002:a92:d084:: with SMTP id h4mr11398865ilh.294.1571221239963; Wed, 16 Oct 2019 03:20:39 -0700 (PDT) MIME-Version: 1.0 References: <20190730155726.26450-1-thomas@monjalon.net> <8145f03d-0911-91a8-73ee-9febe0c1dbec@linux.intel.com> <06588c18-4931-1328-fafe-73c4c02f5c17@intel.com> <42a41fd3-cfa3-2806-f8c2-b6fff2232aa1@intel.com> <8c147be1-ae63-4b90-57ce-fe2644054b98@intel.com> In-Reply-To: <8c147be1-ae63-4b90-57ce-fe2644054b98@intel.com> From: Jerin Jacob Date: Wed, 16 Oct 2019 15:50:28 +0530 Message-ID: To: Ferruh Yigit Cc: Andrew Rybchenko , "Yigit, Ferruh" , Thomas Monjalon , John McNamara , Marko Kovacevic , Ajit Khaparde , Somnath Kotur , John Daley , Hyong Youb Kim , Beilei Xing , Qi Zhang , Wenzhuo Lu , Rosen Xu , Konstantin Ananyev , Shahaf Shuler , Yongseok Koh , Viacheslav Ovsiienko , Rasesh Mody , Shahed Shaikh , dpdk-dev , David Marchand , Adrien Mazarguil Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features 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" On Wed, 16 Oct, 2019, 3:46 PM Ferruh Yigit, wrote: > On 10/16/2019 11:08 AM, Jerin Jacob wrote: > > > > > > On Wed, 16 Oct, 2019, 3:32 PM Ferruh Yigit, > > wrote: > > > > On 10/15/2019 5:19 PM, Jerin Jacob wrote: > > > On Tue, Oct 15, 2019 at 9:26 PM Ferruh Yigit < > ferruh.yigit@intel.com > > > wrote: > > >> > > >> On 10/15/2019 3:16 PM, Jerin Jacob wrote: > > >>>>>>> @@ -36,13 +36,6 @@ VMDq = > > >>>>>>> SR-IOV = > > >>>>>>> DCB = > > >>>>>>> VLAN filter = > > >>>>>>> -Ethertype filter = > > >>>>>>> -N-tuple filter = > > >>>>>>> -SYN filter = > > >>>>>>> -Tunnel filter = > > >>>>>>> -Flexible filter = > > >>>>>>> -Hash filter = > > >>>>>>> -Flow director = > > >>>>>>> Flow control = > > >>>>>>> Flow API = > > >>>>>>> Rate limitation = > > >>>>>> I suggest adding these features back! > > >>>>>> > > >>>>>> "Flow director" and other filters are features that > device/driver > > supports. > > >>>>>> > > >>>>>> And "Flow API" and "filter_ctrl" are methods used to > implement these > > features. > > >>>>>> Indeed they are only different APIs to get input from > application/user. > > >>>>>> > > >>>>>> It doesn't really mean much to say "Flow API" is supported? > So what > > is really > > >>>>>> supported? It matters more what feature is supported. > > >>>>>> > > >>>>>> Since we are saying old method is deprecated, we can update > the > > feature list of > > >>>>>> drivers which implements filtering features using old method > as not > > supported. > > >>>>>> And that is the case with this patch since old APIs are > marked as > > deprecated, > > >>>>>> users can't use them to enable a filtering feature. > > >>>>>> > > >>>>>> Indeed I am for removing the "Flow API" from feature list, > first it > > is not a > > >>>>>> feature, second if it is only method to enable a filtering, > and if > > filtering is > > >>>>>> enabled in a driver, what is the point of redundant "Flow > API" listing? > > >>>>>> > > >>>>>> I can make a quick patch if there is no objection, thanks. > > >>>>> > > >>>>> As I understand it was a decision to avoid details about flow > API support > > >>>>> in features matrix. Mainly because matrix would be really huge > in > > >>>>> attempt to represent it. The question is why filters/patterns > mentioned > > >>>>> above are better than others and should be mentioned. > > >>>>> I'm not against adding some details, just want to understand > criteria. > > >>>>> Flexible and hash are definitely not well defined. > > >>>>> What is flow director and which features should be supported > to say yes? > > >>>>> > > >>> > > >>>> > > >>>> The criteria I have is what users will be interested about a > device/driver. > > >>>> > > >>>> Will it be really huge to list filtering capabilities of the > devices? I > > believe > > >>>> we can group them into a few groups like above. > > >>>> Or at least keep existing one and improve it by time and +1 to > clarify > > them more > > >>>> but that is something else. > > >>>> > > >>>> A device can have capabilities but it is not easy to find if > that > > capability has > > >>>> been enabled via DPDK, this kind of feature matrix works for > it, and all > > >>>> features together makes it much easier than digging datasheets > and code. > > >>>> > > >>>> Saying that "Flow API" is enabled for a driver doesn't really > gives any > > >>>> information to the user if they are interested what kind of > filtering > > features > > >>>> are supported by that device/driver. > > >>> > > >>> I agree. I think, we need to enumerate rte flow patterns and > actions > > >>> supported by the PMD. > > >>> Since there was no single place such documentation, we added the > same > > >>> in PMD documentation > > >>> See 39.8. RTE Flow Support at > > https://doc.dpdk.org/guides/nics/octeontx2.html > > >>> > > >>> And IMO, We should not add deprecated features in the features > matrix as > > >>> new PMDs are not planning to implement the deprecated APIs. That > > >>> makes, matrix looks > > >>> new PMDs do not implement a lot of features, but in reality, > those are > > >>> deprecated and never planning to implement if even though HW > supports it. > > >>> > > >> > > >> +1 to not add deprecated features to the matrix, but those > removed ones > > [1] are > > >> not deprecated. Implementing them via "filter_ctrl" is > deprecated. Below > > >> features still can be implemented via "Flow API", that is why I > am for adding > > >> them back to default.ini. > > > > > > Got it. Instead of [1], Can we document it as in the form of > rte_flow > > > semantics(patterns and actions) so > > > that for the end-user it is very clear. Reason being: > > > # Expressing "Tunnel filter" or "N-tupe filter" or "Flexible > filter" > > > or "Flow director" etc is very vague in rte_flow semantics > > > and function is not just limited with above-fixed functions > > > # The new PMDs also can express the rte_flow aka "Flow API" > support > > > in the rte_flow semantics. > > > > rte_flow is implementation detail, as well as 'filter_ctrl', I > believe listing > > rte_flow semantic will be too much detail for the feature table. > > > > And end user may be interested in features, as if that drive/device > support > > "Flow Director" or not, instead of rte_flow semantic. > > > > But I can see feature being vague is also problem, perhaps we can > have rte_flow > > level details in features.rst file, will it work? > > > > > > > > +1 for adding rte_flow level level details in features.rst > > OK, let me check this > Ok > > > > IMO, Supported packet types(ptype) also good addition in features list. > > "Packet type parsing" feature is already there, > > http://lxr.dpdk.org/dpdk/v19.08/source/doc/guides/nics/features/default.ini#L53 > > If you mean the list of supported types, it is possible to get list on > runtime > via an API, it will be hard to maintain that list in documentation. > Yes. I meant the list of supported types. Ok. I will check the feasibility. > > > > > > > > > > > > >> And announce them as supported per PMD only if they are > implemented via > > Flow API. > > >> > > >> [1] > > >> Ethertype filter = > > >> N-tuple filter = > > >> SYN filter = > > >> Tunnel filter = > > >> Flexible filter = > > >> Hash filter = > > >> Flow director = > > > >