doc: remove deprecated ethdev features
Checks
Commit Message
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(-)
Comments
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>
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...
> -----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>
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>
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.
> > > > 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
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.
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?
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.
> >>> @@ -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.
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 =
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 =
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 =
>
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 =
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 =
>
>
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 =
>
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 =
> >
>
>
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.
@@ -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
@@ -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
@@ -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 =
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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