[dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour

[dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour

[Martin Havlik]

The ability to create RTE flow rules, depending on
port status, can and does differ between PMDs.
Now the doc reflects that.

Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
---
 doc/guides/prog_guide/rte_flow.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..2988e3328a 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3097,6 +3097,10 @@ actually created and a handle returned.
                    const struct rte_flow_action *actions[],
                    struct rte_flow_error *error);
 
+The ability to create a flow rule may depend on the status (started/stopped)
+of the port for which the rule is being created. This behaviour is
+PMD specific. Seek relevant PMD documentation for details.
+
 Arguments:
 
 - ``port_id``: port identifier of Ethernet device.
-- 
2.27.0

[dpdk-dev] [PATCH 3/4] doc: update bonding mode 8023ad info

[Martin Havlik]

Included info on dedicated queues and added related
note about issue on mlx5.

Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
---
 doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
index 30c56cd375..19c65f314c 100644
--- a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
+++ b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
@@ -116,10 +116,18 @@ Currently the Link Bonding PMD library supports following modes of operation:
     #. Calls to ``rte_eth_tx_burst`` must have a buffer size of at least 2xN,
        where N is the number of slaves. This is a space required for LACP
        frames. Additionally LACP packets are included in the statistics, but
        they are not returned to the application.
 
+    This mode also supports enabling dedicated rx and tx queues for handling
+    LACP frames separately from fast application path, resulting in
+    a potential performance improvement.
+
+.. note::
+    Currently mlx5 doesn't work with enabled dedicated queues due to
+    an issue with RTE flow rule creation prior to port start.
+
 *   **Transmit Load Balancing (Mode 5):**
 
 .. figure:: img/bond-mode-5.*
 
    Transmit Load Balancing (Mode 5)
-- 
2.27.0

Re: [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour

[Stephen Hemminger]

On Wed, 21 Jul 2021 17:58:14 +0200
Martin Havlik <xhavli56@stud.fit.vutbr.cz> wrote:

> The ability to create RTE flow rules, depending on
> port status, can and does differ between PMDs.
> Now the doc reflects that.
> 
> Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 2b42d5ec8c..2988e3328a 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -3097,6 +3097,10 @@ actually created and a handle returned.
>                     const struct rte_flow_action *actions[],
>                     struct rte_flow_error *error);
>  
> +The ability to create a flow rule may depend on the status (started/stopped)
> +of the port for which the rule is being created. This behaviour is
> +PMD specific. Seek relevant PMD documentation for details.

Any PMD specific behavior in DPDK is an anathema to application developers
and should be considered a design flaw!

Re: [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour

[Andrew Rybchenko]

On 7/21/21 9:16 PM, Stephen Hemminger wrote:
> On Wed, 21 Jul 2021 17:58:14 +0200
> Martin Havlik <xhavli56@stud.fit.vutbr.cz> wrote:
> 
>> The ability to create RTE flow rules, depending on
>> port status, can and does differ between PMDs.
>> Now the doc reflects that.
>>
>> Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
>> ---
>>   doc/guides/prog_guide/rte_flow.rst | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
>> index 2b42d5ec8c..2988e3328a 100644
>> --- a/doc/guides/prog_guide/rte_flow.rst
>> +++ b/doc/guides/prog_guide/rte_flow.rst
>> @@ -3097,6 +3097,10 @@ actually created and a handle returned.
>>                      const struct rte_flow_action *actions[],
>>                      struct rte_flow_error *error);
>>   
>> +The ability to create a flow rule may depend on the status (started/stopped)
>> +of the port for which the rule is being created. This behaviour is
>> +PMD specific. Seek relevant PMD documentation for details.
> 
> Any PMD specific behavior in DPDK is an anathema to application developers
> and should be considered a design flaw!
> 

+1

Re: [dpdk-dev] [PATCH 3/4] doc: update bonding mode 8023ad info

[Min Hu (Connor)]

Acked-by: Min Hu (Connor) <humin29@huawei.com>

在 2021/7/21 23:58, Martin Havlik 写道:
> Included info on dedicated queues and added related
> note about issue on mlx5.
> 
> Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> ---
>   doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
> diff --git a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
> index 30c56cd375..19c65f314c 100644
> --- a/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
> +++ b/doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
> @@ -116,10 +116,18 @@ Currently the Link Bonding PMD library supports following modes of operation:
>       #. Calls to ``rte_eth_tx_burst`` must have a buffer size of at least 2xN,
>          where N is the number of slaves. This is a space required for LACP
>          frames. Additionally LACP packets are included in the statistics, but
>          they are not returned to the application.
>   
> +    This mode also supports enabling dedicated rx and tx queues for handling
> +    LACP frames separately from fast application path, resulting in
> +    a potential performance improvement.
> +
> +.. note::
> +    Currently mlx5 doesn't work with enabled dedicated queues due to
> +    an issue with RTE flow rule creation prior to port start.
> +
>   *   **Transmit Load Balancing (Mode 5):**
>   
>   .. figure:: img/bond-mode-5.*
>   
>      Transmit Load Balancing (Mode 5)
> 

Re: [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

On Wed, Jul 21, 2021 at 11:16 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed, 21 Jul 2021 17:58:14 +0200
> Martin Havlik <xhavli56@stud.fit.vutbr.cz> wrote:
>
> > The ability to create RTE flow rules, depending on
> > port status, can and does differ between PMDs.
> > Now the doc reflects that.
> >
> > Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> > ---
> >  doc/guides/prog_guide/rte_flow.rst | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> > index 2b42d5ec8c..2988e3328a 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -3097,6 +3097,10 @@ actually created and a handle returned.
> >                     const struct rte_flow_action *actions[],
> >                     struct rte_flow_error *error);
> >
> > +The ability to create a flow rule may depend on the status (started/stopped)
> > +of the port for which the rule is being created. This behaviour is
> > +PMD specific. Seek relevant PMD documentation for details.
>
> Any PMD specific behavior in DPDK is an anathema to application developers
> and should be considered a design flaw!
But it is better to be clear about the behavior.
Drivers and their underlying devices may need certain resources to be
initialized before flows could be created. There may be some drivers
who do not need that.
Specifying ports to be started would cover both the cases.

Maybe then we can say that "some drivers may _not_ need the port to be
started. Check PMD specific documentation".

Re: [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour

[Ori Kam]

Hi

> -----Original Message-----
> From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> Sent: Monday, July 26, 2021 6:07 AM
> 
> On Wed, Jul 21, 2021 at 11:16 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Wed, 21 Jul 2021 17:58:14 +0200
> > Martin Havlik <xhavli56@stud.fit.vutbr.cz> wrote:
> >
> > > The ability to create RTE flow rules, depending on
> > > port status, can and does differ between PMDs.
> > > Now the doc reflects that.
> > >
> > > Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> > > ---
> > >  doc/guides/prog_guide/rte_flow.rst | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> > > index 2b42d5ec8c..2988e3328a 100644
> > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > @@ -3097,6 +3097,10 @@ actually created and a handle returned.
> > >                     const struct rte_flow_action *actions[],
> > >                     struct rte_flow_error *error);
> > >
> > > +The ability to create a flow rule may depend on the status
> (started/stopped)
> > > +of the port for which the rule is being created. This behaviour is
> > > +PMD specific. Seek relevant PMD documentation for details.
> >
> > Any PMD specific behavior in DPDK is an anathema to application
> developers
> > and should be considered a design flaw!
> But it is better to be clear about the behavior.
> Drivers and their underlying devices may need certain resources to be
> initialized before flows could be created. There may be some drivers
> who do not need that.
> Specifying ports to be started would cover both the cases.
> 
> Maybe then we can say that "some drivers may _not_ need the port to be
> started. Check PMD specific documentation".

I don't like the negative approach, if a driver doesn't have any issues with something
it doesn't need to say it support this, the driver may say if it wants to emphasize
but this shouldn't be the default.
I prefer the original suggestion, maybe we can add device cap for this, just like
if a the PMD allows modifying queues after start.

Best
Ori

Re: [dpdk-dev] [PATCH 2/4] doc: specify RTE flow create behaviour

[Ajit Khaparde]

[-- Attachment #1: Type: text/plain, Size: 2392 bytes --]

On Sun, Jul 25, 2021 at 11:46 PM Ori Kam <orika@nvidia.com> wrote:
>
> Hi
>
> > -----Original Message-----
> > From: Ajit Khaparde <ajit.khaparde@broadcom.com>
> > Sent: Monday, July 26, 2021 6:07 AM
> >
> > On Wed, Jul 21, 2021 at 11:16 AM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > On Wed, 21 Jul 2021 17:58:14 +0200
> > > Martin Havlik <xhavli56@stud.fit.vutbr.cz> wrote:
> > >
> > > > The ability to create RTE flow rules, depending on
> > > > port status, can and does differ between PMDs.
> > > > Now the doc reflects that.
> > > >
> > > > Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> > > > ---
> > > >  doc/guides/prog_guide/rte_flow.rst | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > > > index 2b42d5ec8c..2988e3328a 100644
> > > > --- a/doc/guides/prog_guide/rte_flow.rst
> > > > +++ b/doc/guides/prog_guide/rte_flow.rst
> > > > @@ -3097,6 +3097,10 @@ actually created and a handle returned.
> > > >                     const struct rte_flow_action *actions[],
> > > >                     struct rte_flow_error *error);
> > > >
> > > > +The ability to create a flow rule may depend on the status
> > (started/stopped)
> > > > +of the port for which the rule is being created. This behaviour is
> > > > +PMD specific. Seek relevant PMD documentation for details.
> > >
> > > Any PMD specific behavior in DPDK is an anathema to application
> > developers
> > > and should be considered a design flaw!
> > But it is better to be clear about the behavior.
> > Drivers and their underlying devices may need certain resources to be
> > initialized before flows could be created. There may be some drivers
> > who do not need that.
> > Specifying ports to be started would cover both the cases.
> >
> > Maybe then we can say that "some drivers may _not_ need the port to be
> > started. Check PMD specific documentation".
>
> I don't like the negative approach, if a driver doesn't have any issues with something
> it doesn't need to say it support this, the driver may say if it wants to emphasize
> but this shouldn't be the default.
> I prefer the original suggestion, maybe we can add device cap for this, just like
> if a the PMD allows modifying queues after start.
+1.
Device cap should help tie this behavior.

>
> Best
> Ori
>