From: "Rybalchenko, Kirill" <kirill.rybalchenko@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Chilikin, Andrey" <andrey.chilikin@intel.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-dev] [PATCH v3] ethdev: increase flow type limit from 32 to 64
Date: Tue, 16 Jan 2018 10:31:52 +0000 [thread overview]
Message-ID: <696B43C21188DF4F9C9091AAE4789B824E2B886C@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <10699556.vRynAbPGuX@xps>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday 16 January 2018 09:48
> To: Rybalchenko, Kirill <kirill.rybalchenko@intel.com>
> Cc: dev@dpdk.org; Chilikin, Andrey <andrey.chilikin@intel.com>; Yigit,
> Ferruh <ferruh.yigit@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@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.
next prev parent reply other threads:[~2018-01-16 10:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-27 12:29 [dpdk-dev] [PATCH] " Kirill Rybalchenko
2017-12-04 17:43 ` Adrien Mazarguil
2018-01-09 15:16 ` Rybalchenko, Kirill
2018-01-10 13:50 ` Thomas Monjalon
2018-01-16 11:13 ` Adrien Mazarguil
2018-01-16 17:23 ` Rybalchenko, Kirill
2018-01-16 18:03 ` Adrien Mazarguil
2018-01-09 14:30 ` Zhang, Helin
2018-01-10 6:51 ` Xing, Beilei
2018-01-15 16:58 ` [dpdk-dev] [PATCH v2] " Kirill Rybalchenko
2018-01-15 17:33 ` [dpdk-dev] [PATCH v3] " Kirill Rybalchenko
2018-01-15 21:27 ` Thomas Monjalon
2018-01-16 9:44 ` Rybalchenko, Kirill
2018-01-16 9:47 ` Thomas Monjalon
2018-01-16 10:31 ` Rybalchenko, Kirill [this message]
2018-01-16 10:38 ` Thomas Monjalon
2018-01-17 16:56 ` Ferruh Yigit
2018-01-18 9:24 ` Rybalchenko, Kirill
2018-01-18 12:25 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=696B43C21188DF4F9C9091AAE4789B824E2B886C@IRSMSX108.ger.corp.intel.com \
--to=kirill.rybalchenko@intel.com \
--cc=andrey.chilikin@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).