[dpdk-dev] [PATCH v3] ethdev: increase flow type limit from 32 to 64

[Rybalchenko, Kirill]

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Tuesday 16 January 2018 09:48
> To: Rybalchenko, Kirill <kirill.rybalchenko at intel.com>
> Cc: dev at dpdk.org; Chilikin, Andrey <andrey.chilikin at intel.com>; Yigit,
> Ferruh <ferruh.yigit at intel.com>
> Subject: Re: [PATCH v3] ethdev: increase flow type limit from 32 to 64
> 
> 16/01/2018 10:44, Rybalchenko, Kirill:
> > Hi Thomas,
> >
> > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > > 15/01/2018 18:33, Kirill Rybalchenko:
> > > > --- a/lib/librte_ether/rte_eth_ctrl.h
> > > > +++ b/lib/librte_ether/rte_eth_ctrl.h
> > > > @@ -662,9 +662,9 @@ enum rte_fdir_mode {
> > > >         RTE_FDIR_MODE_PERFECT_TUNNEL,   /**< Enable FDIR filter mode
> -
> > > tunnel. */
> > > >  };
> > > >
> > > > -#define UINT32_BIT (CHAR_BIT * sizeof(uint32_t))
> > > > +#define UINT64_BIT (CHAR_BIT * sizeof(uint64_t))
> > > >  #define RTE_FLOW_MASK_ARRAY_SIZE \
> > > > -       (RTE_ALIGN(RTE_ETH_FLOW_MAX, UINT32_BIT)/UINT32_BIT)
> > > > +       (RTE_ALIGN(RTE_ETH_FLOW_MAX, UINT64_BIT)/UINT64_BIT)
> > > >
> > > >  /**
> > > >   * A structure used to get the information of flow director filter.
> > > > @@ -681,7 +681,7 @@ struct rte_eth_fdir_info {
> > > >         uint32_t guarant_spc; /**< Guaranteed spaces.*/
> > > >         uint32_t best_spc; /**< Best effort spaces.*/
> > > >         /** Bit mask for every supported flow type. */
> > > > -       uint32_t flow_types_mask[RTE_FLOW_MASK_ARRAY_SIZE];
> > > > +       uint64_t flow_types_mask[RTE_FLOW_MASK_ARRAY_SIZE];
> > > >         uint32_t max_flexpayload; /**< Total flex payload in bytes. */
> > > >         /** Flexible payload unit in bytes. Size and alignments of all flex
> > > >             payload segments should be multiplies of this value.
> > > > */ @@
> > > > -774,7 +774,7 @@ enum rte_eth_hash_function {  };
> > > >
> > > >  #define RTE_SYM_HASH_MASK_ARRAY_SIZE \
> > > > -       (RTE_ALIGN(RTE_ETH_FLOW_MAX, UINT32_BIT)/UINT32_BIT)
> > > > +       (RTE_ALIGN(RTE_ETH_FLOW_MAX, UINT64_BIT)/UINT64_BIT)
> > > >  /**
> > > >   * A structure used to set or get global hash function configurations
> which
> > > >   * include symmetric hash enable per flow type and hash function type.
> > > > @@ -787,9 +787,9 @@ enum rte_eth_hash_function {  struct
> > > > rte_eth_hash_global_conf {
> > > >         enum rte_eth_hash_function hash_func; /**< Hash function type
> */
> > > >         /** Bit mask for symmetric hash enable per flow type */
> > > > -       uint32_t
> > > sym_hash_enable_mask[RTE_SYM_HASH_MASK_ARRAY_SIZE];
> > > > +       uint64_t
> > > sym_hash_enable_mask[RTE_SYM_HASH_MASK_ARRAY_SIZE];
> > > >         /** Bit mask indicates if the corresponding bit is valid */
> > > > -       uint32_t valid_bit_mask[RTE_SYM_HASH_MASK_ARRAY_SIZE];
> > > > +       uint64_t valid_bit_mask[RTE_SYM_HASH_MASK_ARRAY_SIZE];
> > > >  };
> > >
> > > This is still changing the ABI.
> > > Am I missing something?
> > >
> > We change size of structures rte_eth_fdir_info and
> rte_eth_hash_filter_info.
> 
> Yes, and these structures are allocated and read by the application?
> So it is an ABI break.
If application binary was compiled with previous version of DPDK it makes
no difference if these structures were used internally there - it still will work.
If application binary was recompiled with new version of DPDK - again,
It will work. 
The only issue is if application binary was compiled with old version of DPDK
library, but used with new version of DPDK shared library and uses those
structures to call functions from this DPDK library. But it can be done
only by   rte_eth_dev_filter_ctrl() function, which handles this case properly.
 
> 
> > Application can use these structures for DPDK library API call only in
> > rte_eth_dev_filter_ctrl() function call. In the patch this function is
> > modified in the way that it will be compatible with user binary
> > applications compiled with previous versions of DPDK library.
> 
> Have you tried to use a patched DPDK with a binary compiled with DPDK
> 17.11?

Yes, actually, I did run testpmd from 17.08 with patched DPDK shared library. 
It works fine, as described.

Thanks,
Kirill.