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 7ED27A2EFC for ; Tue, 15 Oct 2019 22:00:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D6EC61EBF2; Tue, 15 Oct 2019 22:00:43 +0200 (CEST) Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com [209.85.210.66]) by dpdk.org (Postfix) with ESMTP id C8EB71EBEE for ; Tue, 15 Oct 2019 22:00:41 +0200 (CEST) Received: by mail-ot1-f66.google.com with SMTP id o44so18060117ota.10 for ; Tue, 15 Oct 2019 13:00:41 -0700 (PDT) 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=2x5ICuSKqwEIbuX5zKaOoeWx4e/Sq9eBYsPxl4Iq278=; b=bfWwsLWhxoGkEPmR9nW365l4DdE8qeWBcrZ4zS9oiaNtMCm5SpZzHiq8FafwNdGyfL 5agyKwDbJarign+DxBTrcBm+jZFjRKfLpR9VjNAZLxw3Ssei4yPqF9Vc5kPPom7d3CA8 ODI/swdEM+GPQKHgNHe++rcSbeIAT6g7/QKhE= 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=2x5ICuSKqwEIbuX5zKaOoeWx4e/Sq9eBYsPxl4Iq278=; b=Lhju8Qtj0sBgcF9ggZD0euo8GeFxLIkcHAbI6dWO0IEg2sYBddnEbUaWDn5uAHJvN8 +b84AwPOEEEqOPygcwj43nT3Us95yRtpXXG2H3PLP4W5hYG6TCpGJZU7yY8i25Yoqpyp xR7EARJwpZiETT9PLq72padfU6urY3y6oeTu2FWI/OGcUOi+4V0TrrvikdOFmi9J5HrS 3JPjc9Mx+tZK8zjDdglNgwkAcKRLnkojsA/eHSCTjTupy5o0civLsjhJT2ghzy3jEUft TE7aNfg1QMitYYnFjVk8LYAN1vSbP180XIevpx/LaRdg2Q+zXlAMt5mWMPfbyi8oQUQo fygA== X-Gm-Message-State: APjAAAVykyHAgo2n6mVMBSLnou1UV7g/1GLzzaoUR2cEwW/U6wPK2A0E zIuK1HA9GWre9TEwELCVu47c+ShtjUkzwtTPTqFlBg== X-Google-Smtp-Source: APXvYqzyBFMnnauq16SkBgnGsJ2lhHnod4lP2mmPBpzMAZOQ9E1e7P+OaqiLP7FtAi63qak3NxiX2bZZ77UdSakeyLA= X-Received: by 2002:a9d:7a96:: with SMTP id l22mr28638757otn.95.1571169640808; Tue, 15 Oct 2019 13:00:40 -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> In-Reply-To: From: Ajit Khaparde Date: Tue, 15 Oct 2019 13:00:22 -0700 Message-ID: To: Jerin Jacob Cc: Ferruh Yigit , Andrew Rybchenko , "Yigit, Ferruh" , Thomas Monjalon , John McNamara , Marko Kovacevic , 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 Tue, Oct 15, 2019 at 9:19 AM Jerin Jacob wrote: > On Tue, Oct 15, 2019 at 9:26 PM Ferruh Yigit > 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. > +1 > > > > 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 = >