mbox series

[v7,0/7] start cleanup of rte_flow_item_*

Message ID 20230203164854.602595-1-ferruh.yigit@amd.com (mailing list archive)
Headers
Series start cleanup of rte_flow_item_* |

Message

Ferruh Yigit Feb. 3, 2023, 4:48 p.m. UTC 
  There was a plan to have structures from lib/net/ at the beginning
of corresponding flow item structures.
Unfortunately this plan has not been followed up so far.
This series is a step to make the most used items,
compliant with the inheritance design explained above.
The old API is kept in anonymous union for compatibility,
but the code in drivers and apps is updated to use the new API.

v7:
 * replace 0xffff -> UINT16_MAX in
   'rte_flow_item_higig2_hdr_mask.hdr.ppt1.classification'
 * drop "GRE protocol struct for flow matching" patch, to fine grain
   using generic fileds better, this will be done later

v6:
 * Fix "struct rte_arp_hdr" field doxygen comment

v5:
 * Fix more RHEL7 build error

v4:
 * Fix build error for RHEL7 (gcc 4.8.5) caused by nested struct
   initialization.

v3:
 * Updated Higig2 protocol flow item assignment taking into account endianness
   annotations.

v2: (by Ferruh)
 * Rebased on latest next-net for v23.03
 * 'struct rte_gre_hdr' endianness annotation added to protocol field
 * more driver code updated for rte_flow_item_eth & rte_flow_item_vlan
 * 'struct rte_gre_hdr' updated to have a combined "rte_be16_t c_rsvd0_ver"
   field and updated drivers accordingly
 * more driver code updated for rte_flow_item_gre
 * more driver code updated for rte_flow_item_gtp

Cc: David Marchand <david.marchand@redhat.com>

Thomas Monjalon (7):
  ethdev: use Ethernet protocol struct for flow matching
  net: add smaller fields for VXLAN
  ethdev: use VXLAN protocol struct for flow matching
  ethdev: use GTP protocol struct for flow matching
  ethdev: use ARP protocol struct for flow matching
  doc: fix description of L2TPV2 flow item
  net: mark all big endian types

 app/test-flow-perf/actions_gen.c         |   2 +-
 app/test-flow-perf/items_gen.c           |  20 +--
 app/test-pmd/cmdline_flow.c              | 166 +++++++++++------------
 doc/guides/prog_guide/rte_flow.rst       |  51 ++-----
 doc/guides/rel_notes/deprecation.rst     |   5 +-
 drivers/net/bnxt/bnxt_flow.c             |  54 ++++----
 drivers/net/bnxt/tf_ulp/ulp_rte_parser.c | 100 +++++++-------
 drivers/net/bonding/rte_eth_bond_pmd.c   |  12 +-
 drivers/net/cxgbe/cxgbe_flow.c           |  44 +++---
 drivers/net/dpaa2/dpaa2_flow.c           |  48 +++----
 drivers/net/dpaa2/dpaa2_mux.c            |   2 +-
 drivers/net/e1000/igb_flow.c             |  14 +-
 drivers/net/enic/enic_flow.c             |  24 ++--
 drivers/net/enic/enic_fm_flow.c          |  16 +--
 drivers/net/hinic/hinic_pmd_flow.c       |  14 +-
 drivers/net/hns3/hns3_flow.c             |  40 +++---
 drivers/net/i40e/i40e_fdir.c             |  14 +-
 drivers/net/i40e/i40e_flow.c             | 124 ++++++++---------
 drivers/net/i40e/i40e_hash.c             |   4 +-
 drivers/net/iavf/iavf_fdir.c             |  18 +--
 drivers/net/iavf/iavf_fsub.c             |  10 +-
 drivers/net/iavf/iavf_ipsec_crypto.c     |   4 +-
 drivers/net/ice/ice_acl_filter.c         |  20 +--
 drivers/net/ice/ice_fdir_filter.c        |  24 ++--
 drivers/net/ice/ice_switch_filter.c      |  64 ++++-----
 drivers/net/igc/igc_flow.c               |   8 +-
 drivers/net/ipn3ke/ipn3ke_flow.c         |  12 +-
 drivers/net/ixgbe/ixgbe_flow.c           |  58 ++++----
 drivers/net/mlx4/mlx4_flow.c             |  38 +++---
 drivers/net/mlx5/hws/mlx5dr_definer.c    |  40 +++---
 drivers/net/mlx5/mlx5_flow.c             |  40 +++---
 drivers/net/mlx5/mlx5_flow_dv.c          | 154 ++++++++++-----------
 drivers/net/mlx5/mlx5_flow_hw.c          |  80 +++++------
 drivers/net/mlx5/mlx5_flow_verbs.c       |  38 +++---
 drivers/net/mlx5/mlx5_trigger.c          |  28 ++--
 drivers/net/mvpp2/mrvl_flow.c            |  28 ++--
 drivers/net/nfp/nfp_flow.c               |  12 +-
 drivers/net/sfc/sfc_flow.c               |  52 +++----
 drivers/net/sfc/sfc_mae.c                |  46 +++----
 drivers/net/tap/tap_flow.c               |  58 ++++----
 drivers/net/txgbe/txgbe_flow.c           |  28 ++--
 lib/ethdev/rte_flow.h                    |  97 ++++++++-----
 lib/net/rte_arp.h                        |  28 ++--
 lib/net/rte_gre.h                        |   2 +-
 lib/net/rte_higig.h                      |   6 +-
 lib/net/rte_mpls.h                       |   2 +-
 lib/net/rte_vxlan.h                      |  35 ++++-
 47 files changed, 904 insertions(+), 880 deletions(-)

--
2.34.1

Comments

fengchengwen Feb. 6, 2023, 2:35 a.m. UTC | #1 
LGTM, Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>

On 2023/2/4 0:48, Ferruh Yigit wrote:
> There was a plan to have structures from lib/net/ at the beginning
> of corresponding flow item structures.
> Unfortunately this plan has not been followed up so far.
> This series is a step to make the most used items,
> compliant with the inheritance design explained above.
> The old API is kept in anonymous union for compatibility,
> but the code in drivers and apps is updated to use the new API.
> 
...
Thomas Monjalon Feb. 7, 2023, 2:58 p.m. UTC | #2 
03/02/2023 17:48, Ferruh Yigit:
> There was a plan to have structures from lib/net/ at the beginning
> of corresponding flow item structures.
> Unfortunately this plan has not been followed up so far.
> This series is a step to make the most used items,
> compliant with the inheritance design explained above.
> The old API is kept in anonymous union for compatibility,
> but the code in drivers and apps is updated to use the new API.

This series looks good, let's merge.
It is only a first step.
We will need to continue using more lib/net/ structures in flow offloads.

A question to answer later after more thoughts,
what is the timeframe to remove old fields?
or do we prefer keeping old flow item fields forever?
Ferruh Yigit Feb. 7, 2023, 4:33 p.m. UTC | #3 
On 2/7/2023 2:58 PM, Thomas Monjalon wrote:
> 03/02/2023 17:48, Ferruh Yigit:
>> There was a plan to have structures from lib/net/ at the beginning
>> of corresponding flow item structures.
>> Unfortunately this plan has not been followed up so far.
>> This series is a step to make the most used items,
>> compliant with the inheritance design explained above.
>> The old API is kept in anonymous union for compatibility,
>> but the code in drivers and apps is updated to use the new API.
> 
> This series looks good, let's merge.

Moving Chengwen's ack too.

> LGTM, Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>
>

Series applied to dpdk-next-net/main, thanks.



> It is only a first step.
> We will need to continue using more lib/net/ structures in flow offloads.
> 

Ack