[dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Thomas Monjalon]

As legacy filter API "filter_ctrl" is superseded since 2017
by the rte_flow API, and got the deprecated attribute in DPDK 19.05,
it is time to remove the associated features from the matrix.
Not documenting deprecated features as supported will avoid confusion.

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
 doc/guides/nics/features.rst             | 78 ------------------------
 doc/guides/nics/features/bnxt.ini        |  3 -
 doc/guides/nics/features/default.ini     |  7 ---
 doc/guides/nics/features/enic.ini        |  1 -
 doc/guides/nics/features/i40e.ini        |  4 --
 doc/guides/nics/features/i40e_vec.ini    |  4 --
 doc/guides/nics/features/i40e_vf.ini     |  1 -
 doc/guides/nics/features/i40e_vf_vec.ini |  1 -
 doc/guides/nics/features/igb.ini         |  4 --
 doc/guides/nics/features/ipn3ke.ini      |  4 --
 doc/guides/nics/features/ixgbe.ini       |  5 --
 doc/guides/nics/features/ixgbe_vec.ini   |  5 --
 doc/guides/nics/features/mlx5.ini        |  1 -
 doc/guides/nics/features/qede.ini        |  3 -
 14 files changed, 121 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 6f8cac2c8..c4e128d2f 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -366,84 +366,6 @@ Supports filtering of a VLAN Tag identifier.
 * **[related]    API**: ``rte_eth_dev_vlan_filter()``.
 
 
-.. _nic_features_ethertype_filter:
-
-Ethertype filter
-----------------
-
-Supports filtering on Ethernet type.
-
-* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_ETHERTYPE``.
-* **[related]    API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``.
-
-.. _nic_features_ntuple_filter:
-
-N-tuple filter
---------------
-
-Supports filtering on N-tuple values.
-
-* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_NTUPLE``.
-* **[related]    API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``.
-
-
-.. _nic_features_syn_filter:
-
-SYN filter
-----------
-
-Supports TCP syn filtering.
-
-* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_SYN``.
-* **[related]    API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``.
-
-
-.. _nic_features_tunnel_filter:
-
-Tunnel filter
--------------
-
-Supports tunnel filtering.
-
-* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_TUNNEL``.
-* **[related]    API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``.
-
-
-.. _nic_features_flexible_filter:
-
-Flexible filter
----------------
-
-Supports a flexible (non-tuple or Ethertype) filter.
-
-* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_FLEXIBLE``.
-* **[related]    API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``.
-
-
-.. _nic_features_hash_filter:
-
-Hash filter
------------
-
-Supports Hash filtering.
-
-* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_HASH``.
-* **[related]    API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``.
-
-
-.. _nic_features_flow_director:
-
-Flow director
--------------
-
-Supports Flow Director style filtering to queues.
-
-* **[implements] eth_dev_ops**: ``filter_ctrl:RTE_ETH_FILTER_FDIR``.
-* **[provides]   mbuf**: ``mbuf.ol_flags:`` ``PKT_RX_FDIR``, ``PKT_RX_FDIR_ID``,
-  ``PKT_RX_FDIR_FLX``.
-* **[related]    API**: ``rte_eth_dev_filter_ctrl()``, ``rte_eth_dev_filter_supported()``.
-
-
 .. _nic_features_flow_control:
 
 Flow control
diff --git a/doc/guides/nics/features/bnxt.ini b/doc/guides/nics/features/bnxt.ini
index a534e3063..9721dd61d 100644
--- a/doc/guides/nics/features/bnxt.ini
+++ b/doc/guides/nics/features/bnxt.ini
@@ -23,9 +23,6 @@ RSS reta update      = Y
 VMDq                 = Y
 SR-IOV               = Y
 VLAN filter          = Y
-Ethertype filter     = Y
-N-tuple filter       = Y
-Flow director        = Y
 Flow control         = Y
 Flow API             = Y
 CRC offload          = Y
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index f1a39d0f0..dfbdf084e 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -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      =
diff --git a/doc/guides/nics/features/enic.ini b/doc/guides/nics/features/enic.ini
index d0f3ae23f..1a065a84f 100644
--- a/doc/guides/nics/features/enic.ini
+++ b/doc/guides/nics/features/enic.ini
@@ -24,7 +24,6 @@ Inner RSS            = Y
 SR-IOV               = Y
 CRC offload          = Y
 VLAN offload         = Y
-Flow director        = Y
 Flow API             = Y
 L3 checksum offload  = Y
 L4 checksum offload  = Y
diff --git a/doc/guides/nics/features/i40e.ini b/doc/guides/nics/features/i40e.ini
index 16eab7f43..980bcc5b2 100644
--- a/doc/guides/nics/features/i40e.ini
+++ b/doc/guides/nics/features/i40e.ini
@@ -25,10 +25,6 @@ VMDq                 = Y
 SR-IOV               = Y
 DCB                  = Y
 VLAN filter          = Y
-Ethertype filter     = Y
-Tunnel filter        = Y
-Hash filter          = Y
-Flow director        = Y
 Flow control         = Y
 Flow API             = Y
 Traffic mirroring    = Y
diff --git a/doc/guides/nics/features/i40e_vec.ini b/doc/guides/nics/features/i40e_vec.ini
index c65e8b036..c878755ef 100644
--- a/doc/guides/nics/features/i40e_vec.ini
+++ b/doc/guides/nics/features/i40e_vec.ini
@@ -23,10 +23,6 @@ VMDq                 = Y
 SR-IOV               = Y
 DCB                  = Y
 VLAN filter          = Y
-Ethertype filter     = Y
-Tunnel filter        = Y
-Hash filter          = Y
-Flow director        = Y
 Flow control         = Y
 Traffic mirroring    = Y
 Timesync             = Y
diff --git a/doc/guides/nics/features/i40e_vf.ini b/doc/guides/nics/features/i40e_vf.ini
index ba2d8cbe9..ab114812c 100644
--- a/doc/guides/nics/features/i40e_vf.ini
+++ b/doc/guides/nics/features/i40e_vf.ini
@@ -18,7 +18,6 @@ RSS hash             = Y
 RSS key update       = Y
 RSS reta update      = Y
 VLAN filter          = Y
-Hash filter          = Y
 CRC offload          = Y
 VLAN offload         = Y
 QinQ offload         = Y
diff --git a/doc/guides/nics/features/i40e_vf_vec.ini b/doc/guides/nics/features/i40e_vf_vec.ini
index 421ed9193..cf7a6c6a2 100644
--- a/doc/guides/nics/features/i40e_vf_vec.ini
+++ b/doc/guides/nics/features/i40e_vf_vec.ini
@@ -18,7 +18,6 @@ RSS hash             = Y
 RSS key update       = Y
 RSS reta update      = Y
 VLAN filter          = Y
-Hash filter          = Y
 Rx descriptor status = Y
 Tx descriptor status = Y
 Basic stats          = Y
diff --git a/doc/guides/nics/features/igb.ini b/doc/guides/nics/features/igb.ini
index c53fd0757..0351f8495 100644
--- a/doc/guides/nics/features/igb.ini
+++ b/doc/guides/nics/features/igb.ini
@@ -22,10 +22,6 @@ VMDq                 = Y
 SR-IOV               = Y
 DCB                  = Y
 VLAN filter          = Y
-Ethertype filter     = Y
-N-tuple filter       = Y
-SYN filter           = Y
-Flexible filter      = Y
 Flow control         = Y
 Flow API             = Y
 CRC offload          = Y
diff --git a/doc/guides/nics/features/ipn3ke.ini b/doc/guides/nics/features/ipn3ke.ini
index a194e3564..47a6526be 100644
--- a/doc/guides/nics/features/ipn3ke.ini
+++ b/doc/guides/nics/features/ipn3ke.ini
@@ -25,10 +25,6 @@ VMDq                 = Y
 SR-IOV               = Y
 DCB                  = Y
 VLAN filter          = Y
-Ethertype filter     = Y
-Tunnel filter        = Y
-Hash filter          = Y
-Flow director        = Y
 Flow control         = Y
 Flow API             = Y
 Traffic mirroring    = Y
diff --git a/doc/guides/nics/features/ixgbe.ini b/doc/guides/nics/features/ixgbe.ini
index 414311176..c412d7af1 100644
--- a/doc/guides/nics/features/ixgbe.ini
+++ b/doc/guides/nics/features/ixgbe.ini
@@ -24,11 +24,6 @@ VMDq                 = Y
 SR-IOV               = Y
 DCB                  = Y
 VLAN filter          = Y
-Ethertype filter     = Y
-N-tuple filter       = Y
-SYN filter           = Y
-Tunnel filter        = Y
-Flow director        = Y
 Flow control         = Y
 Flow API             = Y
 Rate limitation      = Y
diff --git a/doc/guides/nics/features/ixgbe_vec.ini b/doc/guides/nics/features/ixgbe_vec.ini
index ef3ee6880..99098b1c4 100644
--- a/doc/guides/nics/features/ixgbe_vec.ini
+++ b/doc/guides/nics/features/ixgbe_vec.ini
@@ -24,11 +24,6 @@ VMDq                 = Y
 SR-IOV               = Y
 DCB                  = Y
 VLAN filter          = Y
-Ethertype filter     = Y
-N-tuple filter       = Y
-SYN filter           = Y
-Tunnel filter        = Y
-Flow director        = Y
 Flow control         = Y
 Rate limitation      = Y
 Traffic mirroring    = Y
diff --git a/doc/guides/nics/features/mlx5.ini b/doc/guides/nics/features/mlx5.ini
index 75469fc4b..b0a2f8e5f 100644
--- a/doc/guides/nics/features/mlx5.ini
+++ b/doc/guides/nics/features/mlx5.ini
@@ -25,7 +25,6 @@ RSS reta update      = Y
 Inner RSS            = Y
 SR-IOV               = Y
 VLAN filter          = Y
-Flow director        = Y
 Flow control         = Y
 Flow API             = Y
 CRC offload          = Y
diff --git a/doc/guides/nics/features/qede.ini b/doc/guides/nics/features/qede.ini
index f69e4f843..20c90e626 100644
--- a/doc/guides/nics/features/qede.ini
+++ b/doc/guides/nics/features/qede.ini
@@ -19,9 +19,6 @@ RSS hash             = Y
 RSS key update       = Y
 RSS reta update      = Y
 VLAN filter          = Y
-N-tuple filter       = Y
-Tunnel filter        = Y
-Flow director        = Y
 Flow control         = Y
 Flow API             = Y
 CRC offload          = Y
-- 
2.21.0

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Andrew Rybchenko]

On 7/30/19 6:57 PM, Thomas Monjalon wrote:
> As legacy filter API "filter_ctrl" is superseded since 2017
> by the rte_flow API, and got the deprecated attribute in DPDK 19.05,
> it is time to remove the associated features from the matrix.
> Not documenting deprecated features as supported will avoid confusion.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[David Marchand]

On Tue, Jul 30, 2019 at 5:58 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> As legacy filter API "filter_ctrl" is superseded since 2017
> by the rte_flow API, and got the deprecated attribute in DPDK 19.05,
> it is time to remove the associated features from the matrix.
> Not documenting deprecated features as supported will avoid confusion.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
>  doc/guides/nics/features.rst             | 78 ------------------------
>  doc/guides/nics/features/bnxt.ini        |  3 -
>  doc/guides/nics/features/default.ini     |  7 ---
>  doc/guides/nics/features/enic.ini        |  1 -
>  doc/guides/nics/features/i40e.ini        |  4 --
>  doc/guides/nics/features/i40e_vec.ini    |  4 --
>  doc/guides/nics/features/i40e_vf.ini     |  1 -
>  doc/guides/nics/features/i40e_vf_vec.ini |  1 -
>  doc/guides/nics/features/igb.ini         |  4 --
>  doc/guides/nics/features/ipn3ke.ini      |  4 --
>  doc/guides/nics/features/ixgbe.ini       |  5 --
>  doc/guides/nics/features/ixgbe_vec.ini   |  5 --
>  doc/guides/nics/features/mlx5.ini        |  1 -
>  doc/guides/nics/features/qede.ini        |  3 -
>  14 files changed, 121 deletions(-)

The drivers docs still list and/or describe those features.
Is this intended ?

Example:
https://git.dpdk.org/dpdk/tree/doc/guides/nics/enic.rst#n505
https://git.dpdk.org/dpdk/tree/doc/guides/nics/i40e.rst#n16
etc...


-- 
David Marchand

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Jerin Jacob Kollanukkaran]

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
> Sent: Wednesday, July 31, 2019 3:04 PM
> To: Thomas Monjalon <thomas@monjalon.net>; John McNamara
> <john.mcnamara@intel.com>; Marko Kovacevic
> <marko.kovacevic@intel.com>; Ajit Khaparde
> <ajit.khaparde@broadcom.com>; Somnath Kotur
> <somnath.kotur@broadcom.com>; Ferruh Yigit <ferruh.yigit@intel.com>;
> John Daley <johndale@cisco.com>; Hyong Youb Kim <hyonkim@cisco.com>;
> Beilei Xing <beilei.xing@intel.com>; Qi Zhang <qi.z.zhang@intel.com>;
> Wenzhuo Lu <wenzhuo.lu@intel.com>; Rosen Xu <rosen.xu@intel.com>;
> Konstantin Ananyev <konstantin.ananyev@intel.com>; Shahaf Shuler
> <shahafs@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>;
> Viacheslav Ovsiienko <viacheslavo@mellanox.com>; Rasesh Mody
> <rmody@marvell.com>; Shahed Shaikh <shshaikh@marvell.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features
> 
> On 7/30/19 6:57 PM, Thomas Monjalon wrote:
> > As legacy filter API "filter_ctrl" is superseded since 2017 by the
> > rte_flow API, and got the deprecated attribute in DPDK 19.05, it is
> > time to remove the associated features from the matrix.
> > Not documenting deprecated features as supported will avoid confusion.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> 
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>

Acked-by: Jerin Jacob <jerinj@marvell.com>

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Ajit Khaparde]

On Wed, Jul 31, 2019 at 3:35 AM Jerin Jacob Kollanukkaran <
jerinj@marvell.com> wrote:

> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Rybchenko
> > Sent: Wednesday, July 31, 2019 3:04 PM
> > To: Thomas Monjalon <thomas@monjalon.net>; John McNamara
> > <john.mcnamara@intel.com>; Marko Kovacevic
> > <marko.kovacevic@intel.com>; Ajit Khaparde
> > <ajit.khaparde@broadcom.com>; Somnath Kotur
> > <somnath.kotur@broadcom.com>; Ferruh Yigit <ferruh.yigit@intel.com>;
> > John Daley <johndale@cisco.com>; Hyong Youb Kim <hyonkim@cisco.com>;
> > Beilei Xing <beilei.xing@intel.com>; Qi Zhang <qi.z.zhang@intel.com>;
> > Wenzhuo Lu <wenzhuo.lu@intel.com>; Rosen Xu <rosen.xu@intel.com>;
> > Konstantin Ananyev <konstantin.ananyev@intel.com>; Shahaf Shuler
> > <shahafs@mellanox.com>; Yongseok Koh <yskoh@mellanox.com>;
> > Viacheslav Ovsiienko <viacheslavo@mellanox.com>; Rasesh Mody
> > <rmody@marvell.com>; Shahed Shaikh <shshaikh@marvell.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features
> >
> > On 7/30/19 6:57 PM, Thomas Monjalon wrote:
> > > As legacy filter API "filter_ctrl" is superseded since 2017 by the
> > > rte_flow API, and got the deprecated attribute in DPDK 19.05, it is
> > > time to remove the associated features from the matrix.
> > > Not documenting deprecated features as supported will avoid confusion.
> > >
> > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> >
> > Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>
> Acked-by: Jerin Jacob <jerinj@marvell.com>
>

Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Thomas Monjalon]

31/07/2019 11:45, David Marchand:
> On Tue, Jul 30, 2019 at 5:58 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > As legacy filter API "filter_ctrl" is superseded since 2017
> > by the rte_flow API, and got the deprecated attribute in DPDK 19.05,
> > it is time to remove the associated features from the matrix.
> > Not documenting deprecated features as supported will avoid confusion.
> >
> > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > ---
> >  doc/guides/nics/features.rst             | 78 ------------------------
> >  doc/guides/nics/features/bnxt.ini        |  3 -
> >  doc/guides/nics/features/default.ini     |  7 ---
> >  doc/guides/nics/features/enic.ini        |  1 -
> >  doc/guides/nics/features/i40e.ini        |  4 --
> >  doc/guides/nics/features/i40e_vec.ini    |  4 --
> >  doc/guides/nics/features/i40e_vf.ini     |  1 -
> >  doc/guides/nics/features/i40e_vf_vec.ini |  1 -
> >  doc/guides/nics/features/igb.ini         |  4 --
> >  doc/guides/nics/features/ipn3ke.ini      |  4 --
> >  doc/guides/nics/features/ixgbe.ini       |  5 --
> >  doc/guides/nics/features/ixgbe_vec.ini   |  5 --
> >  doc/guides/nics/features/mlx5.ini        |  1 -
> >  doc/guides/nics/features/qede.ini        |  3 -
> >  14 files changed, 121 deletions(-)
> 
> The drivers docs still list and/or describe those features.
> Is this intended ?
> 
> Example:
> https://git.dpdk.org/dpdk/tree/doc/guides/nics/enic.rst#n505
> https://git.dpdk.org/dpdk/tree/doc/guides/nics/i40e.rst#n16
> etc...

Yes, we should find the same features with the legacy API
and rte_flow. I think each PMD can adjust their documentation
while finishing the migration to rte_flow API.

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Thomas Monjalon]

> > > > As legacy filter API "filter_ctrl" is superseded since 2017 by the
> > > > rte_flow API, and got the deprecated attribute in DPDK 19.05, it is
> > > > time to remove the associated features from the matrix.
> > > > Not documenting deprecated features as supported will avoid confusion.
> > > >
> > > > Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> > > Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> > Acked-by: Jerin Jacob <jerinj@marvell.com>
> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>

Applied

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Yigit, Ferruh]

On 7/30/2019 4:57 PM, Thomas Monjalon wrote:
> As legacy filter API "filter_ctrl" is superseded since 2017
> by the rte_flow API, and got the deprecated attribute in DPDK 19.05,
> it is time to remove the associated features from the matrix.
> Not documenting deprecated features as supported will avoid confusion.
> 
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

<...>

> diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
> index f1a39d0f0..dfbdf084e 100644
> --- a/doc/guides/nics/features/default.ini
> +++ b/doc/guides/nics/features/default.ini
> @@ -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.

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Andrew Rybchenko]

Cc Adrien

On 10/15/19 2:08 PM, Yigit, Ferruh wrote:
> On 7/30/2019 4:57 PM, Thomas Monjalon wrote:
>> As legacy filter API "filter_ctrl" is superseded since 2017
>> by the rte_flow API, and got the deprecated attribute in DPDK 19.05,
>> it is time to remove the associated features from the matrix.
>> Not documenting deprecated features as supported will avoid confusion.
>>
>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> <...>
>
>> diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
>> index f1a39d0f0..dfbdf084e 100644
>> --- a/doc/guides/nics/features/default.ini
>> +++ b/doc/guides/nics/features/default.ini
>> @@ -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?

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Ferruh Yigit]

On 10/15/2019 1:31 PM, Andrew Rybchenko wrote:
> Cc Adrien
> 
> On 10/15/19 2:08 PM, Yigit, Ferruh wrote:
>> On 7/30/2019 4:57 PM, Thomas Monjalon wrote:
>>> As legacy filter API "filter_ctrl" is superseded since 2017
>>> by the rte_flow API, and got the deprecated attribute in DPDK 19.05,
>>> it is time to remove the associated features from the matrix.
>>> Not documenting deprecated features as supported will avoid confusion.
>>>
>>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> <...>
>>
>>> diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
>>> index f1a39d0f0..dfbdf084e 100644
>>> --- a/doc/guides/nics/features/default.ini
>>> +++ b/doc/guides/nics/features/default.ini
>>> @@ -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.

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Jerin Jacob]

> >>> @@ -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.

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Ferruh Yigit]

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.
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        =

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Jerin Jacob]

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.


> 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        =

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Ajit Khaparde]

On Tue, Oct 15, 2019 at 9:19 AM Jerin Jacob <jerinjacobk@gmail.com> 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.
>
+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        =
>

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Ferruh Yigit]

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?

> 
> 
>> 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        =

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Jerin Jacob]

On Wed, 16 Oct, 2019, 3:32 PM Ferruh Yigit, <ferruh.yigit@intel.com> 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

IMO, Supported packet types(ptype) also good addition in features list.


> >
> >
> >> 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        =
>
>

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Ferruh Yigit]

On 10/16/2019 11:08 AM, Jerin Jacob wrote:
> 
> 
> On Wed, 16 Oct, 2019, 3:32 PM Ferruh Yigit, <ferruh.yigit@intel.com
> <mailto:ferruh.yigit@intel.com>> 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
>     <mailto: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

> 
> 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.

> 
> 
>     >
>     >
>     >> 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        =
> 

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Jerin Jacob]

On Wed, 16 Oct, 2019, 3:46 PM Ferruh Yigit, <ferruh.yigit@intel.com> wrote:

> On 10/16/2019 11:08 AM, Jerin Jacob wrote:
> >
> >
> > On Wed, 16 Oct, 2019, 3:32 PM Ferruh Yigit, <ferruh.yigit@intel.com
> > <mailto:ferruh.yigit@intel.com>> 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
> >     <mailto: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        =
> >
>
>

Re: [dpdk-dev] [PATCH] doc: remove deprecated ethdev features

[Thomas Monjalon]

16/10/2019 12:20, Jerin Jacob:
> On Wed, 16 Oct, 2019, 3:46 PM Ferruh Yigit, <ferruh.yigit@intel.com> wrote:
> 
> > On 10/16/2019 11:08 AM, Jerin Jacob wrote:
> > >
> > >
> > > On Wed, 16 Oct, 2019, 3:32 PM Ferruh Yigit, <ferruh.yigit@intel.com
> > > <mailto:ferruh.yigit@intel.com>> 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
> > >     <mailto: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

Just to confirm my thought:
The name of the removed "features" came from the filter API,
which is very similar to Intel datasheets.
In rte_flow API, these categories may not make sense.
I am OK to not refer to rte_flow but to show the real implemented features,
if you find a way to express them concisely.


> > > 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.

We need to be careful about the size of this matrix.
We can split in several matrix if needed.