mbox series

[v3,0/6] Flow entites behavior on port restart

Message ID 20211019123722.3414694-1-dkozlyuk@nvidia.com (mailing list archive)
Headers
Series Flow entites behavior on port restart |

Message

Dmitry Kozlyuk Oct. 19, 2021, 12:37 p.m. UTC 
  It is unspecified whether flow rules and indirect actions are kept
when a port is stopped, possibly reconfigured, and started again.
Vendors approach the topic differently, e.g. mlx5 and i40e PMD
disagree in whether flow rules can be kept, and mlx5 PMD would keep
indirect actions. In the end, applications are greatly affected
by whatever contract there is and need to know it.

It is proposed to advertise capabilities of keeping flow rules
and indirect actions (as a special case of shared object)
using a combination of ethdev info and rte_flow calls.
Then a bug is fixed in mlx5 PMD that prevented indirect RSS action
from being kept, and the driver starts advertising the new capability.

Prior discussions:
1) http://inbox.dpdk.org/dev/20210727073121.895620-1-dkozlyuk@nvidia.com/
2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-dkozlyuk@nvidia.com/

v3:  1. Add a patch 3/6 to update all PMDs that implement rte_flow
        with an explicit reset of the new capability (Ferruh).
     2. Change how the support of keeping particular kinds
        of flow rules is determined, improve wording (Andrew).
     3. Do not require keeping rules and indirect actions
        across reconfiguration (Qi Zhang).
     4. Improve wording (Ori).

Dmitry Kozlyuk (6):
  ethdev: add capability to keep flow rules on restart
  ethdev: add capability to keep shared objects on restart
  net: advertise no support for keeping flow rules
  net/mlx5: discover max flow priority using DevX
  net/mlx5: create drop queue using DevX
  net/mlx5: preserve indirect actions on restart

 doc/guides/prog_guide/rte_flow.rst      |  49 ++++
 drivers/net/bnxt/bnxt_ethdev.c          |   1 +
 drivers/net/bnxt/bnxt_reps.c            |   1 +
 drivers/net/cnxk/cnxk_ethdev_ops.c      |   1 +
 drivers/net/cxgbe/cxgbe_ethdev.c        |   2 +
 drivers/net/dpaa2/dpaa2_ethdev.c        |   1 +
 drivers/net/e1000/em_ethdev.c           |   2 +
 drivers/net/e1000/igb_ethdev.c          |   1 +
 drivers/net/enic/enic_ethdev.c          |   1 +
 drivers/net/failsafe/failsafe_ops.c     |   1 +
 drivers/net/hinic/hinic_pmd_ethdev.c    |   2 +
 drivers/net/hns3/hns3_ethdev.c          |   1 +
 drivers/net/hns3/hns3_ethdev_vf.c       |   1 +
 drivers/net/i40e/i40e_ethdev.c          |   1 +
 drivers/net/i40e/i40e_vf_representor.c  |   2 +
 drivers/net/iavf/iavf_ethdev.c          |   1 +
 drivers/net/ice/ice_dcf_ethdev.c        |   1 +
 drivers/net/igc/igc_ethdev.c            |   1 +
 drivers/net/ipn3ke/ipn3ke_representor.c |   1 +
 drivers/net/mlx5/linux/mlx5_os.c        |   5 -
 drivers/net/mlx5/mlx5_devx.c            | 211 ++++++++++++++---
 drivers/net/mlx5/mlx5_ethdev.c          |   1 +
 drivers/net/mlx5/mlx5_flow.c            | 292 ++++++++++++++++++++++--
 drivers/net/mlx5/mlx5_flow.h            |   6 +
 drivers/net/mlx5/mlx5_flow_dv.c         | 103 +++++++++
 drivers/net/mlx5/mlx5_flow_verbs.c      |  77 +------
 drivers/net/mlx5/mlx5_rx.h              |   4 +
 drivers/net/mlx5/mlx5_rxq.c             |  99 +++++++-
 drivers/net/mlx5/mlx5_trigger.c         |  10 +
 drivers/net/mvpp2/mrvl_ethdev.c         |   2 +
 drivers/net/octeontx2/otx2_ethdev_ops.c |   1 +
 drivers/net/qede/qede_ethdev.c          |   1 +
 drivers/net/sfc/sfc_ethdev.c            |   1 +
 drivers/net/softnic/rte_eth_softnic.c   |   1 +
 drivers/net/tap/rte_eth_tap.c           |   1 +
 drivers/net/txgbe/txgbe_ethdev.c        |   1 +
 drivers/net/txgbe/txgbe_ethdev_vf.c     |   1 +
 lib/ethdev/rte_ethdev.h                 |  10 +
 lib/ethdev/rte_flow.h                   |   1 +
 39 files changed, 762 insertions(+), 137 deletions(-)

Comments

Andrew Rybchenko Oct. 20, 2021, 10:12 a.m. UTC | #1 
On 10/19/21 3:37 PM, Dmitry Kozlyuk wrote:
> It is unspecified whether flow rules and indirect actions are kept
> when a port is stopped, possibly reconfigured, and started again.
> Vendors approach the topic differently, e.g. mlx5 and i40e PMD
> disagree in whether flow rules can be kept, and mlx5 PMD would keep
> indirect actions. In the end, applications are greatly affected
> by whatever contract there is and need to know it.
> 
> It is proposed to advertise capabilities of keeping flow rules
> and indirect actions (as a special case of shared object)
> using a combination of ethdev info and rte_flow calls.
> Then a bug is fixed in mlx5 PMD that prevented indirect RSS action
> from being kept, and the driver starts advertising the new capability.
> 
> Prior discussions:
> 1) http://inbox.dpdk.org/dev/20210727073121.895620-1-dkozlyuk@nvidia.com/
> 2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-dkozlyuk@nvidia.com/

Is there real usecase for keeping flow rules or indirect
actions?
Why does application want to restart port?
Dmitry Kozlyuk Oct. 20, 2021, 1:21 p.m. UTC | #2 
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: 20 октября 2021 г. 13:12
> To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/6] Flow entites behavior on port
> restart
> 
> External email: Use caution opening links or attachments
> 
> 
> On 10/19/21 3:37 PM, Dmitry Kozlyuk wrote:
> > It is unspecified whether flow rules and indirect actions are kept
> > when a port is stopped, possibly reconfigured, and started again.
> > Vendors approach the topic differently, e.g. mlx5 and i40e PMD
> > disagree in whether flow rules can be kept, and mlx5 PMD would keep
> > indirect actions. In the end, applications are greatly affected
> > by whatever contract there is and need to know it.
> >
> > It is proposed to advertise capabilities of keeping flow rules
> > and indirect actions (as a special case of shared object)
> > using a combination of ethdev info and rte_flow calls.
> > Then a bug is fixed in mlx5 PMD that prevented indirect RSS action
> > from being kept, and the driver starts advertising the new capability.
> >
> > Prior discussions:
> > 1) http://inbox.dpdk.org/dev/20210727073121.895620-1-
> dkozlyuk@nvidia.com/
> > 2) http://inbox.dpdk.org/dev/20210901085516.3647814-1-
> dkozlyuk@nvidia.com/
> 
> Is there real usecase for keeping flow rules or indirect
> actions?
> Why does application want to restart port?

Sorry, I don't know of real use cases that would already use this feature.
But on the other hand, there was no well-defined API to enable such apps.
I can imagine apps adding queues (if their setup after the start is unsupported)
and enabling offloads when available resources or traffic pattern changes,
e.g. a DDoS attack starts and checksum calculation now wastes cycles on garbage.

For indirect actions, as patch 2/6 mentions, persistent semantics
are either natural (counters, meters) or just convenient.
Working around with shifts for counters or tolerances for meters
is possible of course, but it increases application state to manage.
 
For rules,
1. It is worth noting that an app can create many of them
before stopping a port, like a rule for each connection.
Saving the application from tracking them in such case is a big advantage.
If they cannot be restored before the port is started again,
there will be a time gap when the traffic is flowing, but no rules process it.
This alone could be covered by a distinct capability proposed earlier [1].
2. However, nowadays, there are apps that create rules on their datapath.
If rules are kept, such apps can reconfigure ports without
either loosing the rules or having to track them very fast.
As it is explained in the comments to patch 1/6 and 2/6,
now that rules can exist when the port is not stated,
it is logical that they need not be destroyed when the port is stopped.

[1]: http://patchwork.dpdk.org/project/dpdk/patch/20211005171914.2936-1-xhavli56@stud.fit.vutbr.cz/