From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4DB3FA057C; Fri, 27 Mar 2020 15:37:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 30F651C208; Fri, 27 Mar 2020 15:37:08 +0100 (CET) Received: from relay0121.mxlogin.com (relay0121.mxlogin.com [199.181.239.121]) by dpdk.org (Postfix) with ESMTP id EDA041C206 for ; Fri, 27 Mar 2020 15:37:06 +0100 (CET) Received: from filter003.mxroute.com ([168.235.111.26] 168-235-111-26.cloud.ramnode.com) (Authenticated sender: mN4UYu2MZsgR) by relay0121.mxlogin.com (ZoneMTA) with ESMTPSA id 1711c6cbfa80000766.002 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 27 Mar 2020 14:37:01 +0000 X-Zone-Loop: e433d41cba9595b9677fd8db11453a9f437ee1c17a16 X-Originating-IP: [168.235.111.26] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter003.mxroute.com (Postfix) with ESMTPS id 5EFCC635EF; Fri, 27 Mar 2020 14:36:55 +0000 (UTC) Received: from [134.191.227.39] by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1jHpis-000579-OG; Fri, 27 Mar 2020 10:12:35 -0400 To: "Van Haaren, Harry" , Thomas Monjalon , Neil Horman , Dodji Seketeli Cc: David Marchand , "Laatz, Kevin" , dev , "Richardson, Bruce" , Honnappa Nagarahalli References: <20200324114921.7184-1-kevin.laatz@intel.com> <20200327134441.GA3540715@hmswarspite.think-freely.org> <1849712.2IRrRt1zHL@xps> From: Ray Kinsella Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: Date: Fri, 27 Mar 2020 14:36:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AuthUser: mdr@ashroe.eu Subject: Re: [dpdk-dev] [PATCH v2] eal/cpuflags: add x86 based cpu flags 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 27/03/2020 14:32, Van Haaren, Harry wrote: >> -----Original Message----- >> From: Thomas Monjalon >> Sent: Friday, March 27, 2020 2:16 PM >> To: Neil Horman ; Dodji Seketeli ; >> mdr@ashroe.eu >> Cc: David Marchand ; Laatz, Kevin >> ; dev ; Richardson, Bruce >> ; Van Haaren, Harry ; >> Honnappa Nagarahalli >> Subject: Re: [dpdk-dev] [PATCH v2] eal/cpuflags: add x86 based cpu flags >> >> 27/03/2020 14:44, Neil Horman: >>> On Fri, Mar 27, 2020 at 01:24:12PM +0100, David Marchand wrote: >>>> On Wed, Mar 25, 2020 at 12:11 PM Kevin Laatz >> wrote: >>>>> --- a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h >>>>> +++ b/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h >>>>> @@ -113,6 +113,24 @@ enum rte_cpu_flag_t { >>>>> /* (EAX 80000007h) EDX features */ >>>>> RTE_CPUFLAG_INVTSC, /**< INVTSC */ >>>>> >>>>> + RTE_CPUFLAG_AVX512DQ, /**< AVX512 Doubleword and >> Quadword */ >>>>> + RTE_CPUFLAG_AVX512IFMA, /**< AVX512 Integer Fused >> Multiply-Add */ >>>>> + RTE_CPUFLAG_AVX512CD, /**< AVX512 Conflict >> Detection*/ >>>>> + RTE_CPUFLAG_AVX512BW, /**< AVX512 Byte and Word */ >>>>> + RTE_CPUFLAG_AVX512VL, /**< AVX512 Vector Length */ >>>>> + RTE_CPUFLAG_AVX512VBMI, /**< AVX512 Vector Bit >> Manipulation */ >>>>> + RTE_CPUFLAG_AVX512VBMI2, /**< AVX512 Vector Bit >> Manipulation 2 */ >>>>> + RTE_CPUFLAG_GFNI, /**< Galois Field New >> Instructions */ >>>>> + RTE_CPUFLAG_VAES, /**< Vector AES */ >>>>> + RTE_CPUFLAG_VPCLMULQDQ, /**< Vector Carry-less >> Multiply */ >>>>> + RTE_CPUFLAG_AVX512VNNI, /**< AVX512 Vector Neural >> Network Instructions */ >>>>> + RTE_CPUFLAG_AVX512BITALG, /**< AVX512 Bit Algorithms >> */ >>>>> + RTE_CPUFLAG_AVX512VPOPCNTDQ, /**< AVX512 Vector Popcount >> */ >>>>> + RTE_CPUFLAG_CLDEMOTE, /**< Cache Line Demote */ >>>>> + RTE_CPUFLAG_MOVDIRI, /**< Direct Store >> Instructions */ >>>>> + RTE_CPUFLAG_MOVDIR64B, /**< Direct Store >> Instructions 64B */ >>>>> + RTE_CPUFLAG_AVX512VP2INTERSECT, /**< AVX512 Two Register >> Intersection */ >>>>> + >>>>> /* The last item */ >>>>> RTE_CPUFLAG_NUMFLAGS, /**< This should always be >> the last! */ >>>> >>>> This is seen as an ABI break because of the change on _NUMFLAGS: >>>> https://travis-ci.com/github/ovsrobot/dpdk/jobs/302524264#L2351 >>>> >>> It shouldn't be, as the only API calls we expose that use rte_cpu_flag_t >> accept >>> it as an integer parameter to see if the flag is enabled. Theres no use of >> the >>> enum in a public array or any struct that is sized based on the number of >> flags, >>> so you should be good to go >> >> Indeed I cannot imagine an ABI incompatibility in this case. >> The only behaviour change is to accept new (higher) RTE_CPUFLAG values >> in functions rte_cpu_get_flag_enabled() and rte_cpu_get_flag_name(). >> Is changing the range of valid values an ABI break? >> Why is it flagged by libabigail? > > If this enum _MAX value was used by the application to allocate an array, that later our DPDK code would write to it could cause out-of-bounds array accesses of the application supplied array. Abigail doesn't know what applications could use the value for, so it flags it. > > IMO Abigail is right to flag it to us - a manual review to understand what that _MAX enum value is used for, and then decide on a case by case basis seems the best way forward to me. > > Thanks Neil/Thomas for reviewing, as reply in this thread, I also believe this is not going to break ABI. > +1 to Harrry's comments. I can't immediately see how this might break the ABI either.