From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 42D232904 for ; Tue, 16 Jan 2018 11:31:55 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 02:31:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,367,1511856000"; d="scan'208";a="11310605" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by fmsmga002.fm.intel.com with ESMTP; 16 Jan 2018 02:31:54 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by irsmsx110.ger.corp.intel.com ([163.33.3.25]) with mapi id 14.03.0319.002; Tue, 16 Jan 2018 10:31:52 +0000 From: "Rybalchenko, Kirill" To: Thomas Monjalon CC: "dev@dpdk.org" , "Chilikin, Andrey" , "Yigit, Ferruh" Thread-Topic: [PATCH v3] ethdev: increase flow type limit from 32 to 64 Thread-Index: AQHTjicH0YkZuC2WLEehtsH01cKhYKN1cvyAgADLxWCAAAMHAIAACdlA Date: Tue, 16 Jan 2018 10:31:52 +0000 Message-ID: <696B43C21188DF4F9C9091AAE4789B824E2B886C@IRSMSX108.ger.corp.intel.com> References: <1516035500-6010-1-git-send-email-kirill.rybalchenko@intel.com> <1777513.sriIylAOkO@xps> <696B43C21188DF4F9C9091AAE4789B824E2B8810@IRSMSX108.ger.corp.intel.com> <10699556.vRynAbPGuX@xps> In-Reply-To: <10699556.vRynAbPGuX@xps> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTYxMjNiOGYtZGRkZi00YWZjLWFmZTQtYmJkZjU0NTY0OTg1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6InNrN3RxOEZaVklZdEF2SDZqNFJRb2pYQkY5dWNuaUtaN2t0NjhJeUk5aXM9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3] ethdev: increase flow type limit from 32 to 64 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 10:31:56 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Tuesday 16 January 2018 09:48 > To: Rybalchenko, Kirill > Cc: dev@dpdk.org; Chilikin, Andrey ; Yigit, > Ferruh > Subject: Re: [PATCH v3] ethdev: increase flow type limit from 32 to 64 >=20 > 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 mod= e > - > > > 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 configurati= ons > which > > > > * include symmetric hash enable per flow type and hash function t= ype. > > > > @@ -787,9 +787,9 @@ enum rte_eth_hash_function { struct > > > > rte_eth_hash_global_conf { > > > > enum rte_eth_hash_function hash_func; /**< Hash function ty= pe > */ > > > > /** 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. >=20 > 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 wil= l work. If application binary was recompiled with new version of DPDK - again, It will work.=20 The only issue is if application binary was compiled with old version of DP= DK 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 prope= rly. =20 >=20 > > 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. >=20 > 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 librar= y.=20 It works fine, as described. Thanks, Kirill.