From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6518E4293E; Fri, 14 Apr 2023 11:22:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3B63B40144; Fri, 14 Apr 2023 11:22:42 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 41FCF410FA for ; Fri, 14 Apr 2023 11:22:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681464159; x=1713000159; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=XWLpy8JP8M3TeOVrgmsKRHQHFZBtjsc9jhYx5G/uitk=; b=QKlwJREq6/jNj8R+SbbTU/gmI2YoyrL81YIk//t/u5uMQJoSDqy14S3H OeMFsmQvhfA8j8OwH1M5abz7s3eSWPyYorlxP8kzicSNiM8rNEnF+BUlZ 1UtUBH+eLO+mB3MtfWfR3BjtJx70DXq9ZycIL3E1IY6Q0YhXDCW3xvKPA uESCeCKq/efRl1/dFXXaXd807E3IJxqoSJ+G9hTAxKfBGNkVkY+4UdOaH GrW4ewzxNDZYCB5HRrXDrlX5TGWf8wWDAIUu6IGd979/po/NDTzdPu5zJ hGZ/Uhdvr9jjGXV1svN6+1gmvIGLKJU0bHBFTabipegoiZ9Rj9fvEaBtD A==; X-IronPort-AV: E=McAfee;i="6600,9927,10679"; a="409623749" X-IronPort-AV: E=Sophos;i="5.99,195,1677571200"; d="scan'208";a="409623749" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Apr 2023 02:22:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10679"; a="640055556" X-IronPort-AV: E=Sophos;i="5.99,195,1677571200"; d="scan'208";a="640055556" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga003.jf.intel.com with ESMTP; 14 Apr 2023 02:22:27 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 14 Apr 2023 02:22:26 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23 via Frontend Transport; Fri, 14 Apr 2023 02:22:26 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.103) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Fri, 14 Apr 2023 02:22:26 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=efhTLhx5ds5hAECmY8ErQB3+dnu2xB+xLpRZ3fqYeHQ9ciLrzrrGIQDFNFl0ufJRSbGwKvTbewkg9YcGj6co4K8hjDLLSzZKYClc2F97oEVLxN9IKToLWYEbLeMwGrLW1jgPj+Wv6UkvIkCR5BPzqXdrVwiMULAwNOPxuaYqLQwJO+jkGj+EvUHQegvRMVIh2qCOoxfzbRiJA0Ja60jBbwuWrqJko3GZALtG+OsL9B56NIHR1ZH2fYKfdA9YKWaVLfWJwpK83RKmAf/wO1xzic8wYRkMq+QZLHtcYjC0a9TS13PuySdul0KcrxAhevxMgftXEd0QUtHJkCSql8ESnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qJFTGYgWTF/b/5rTFHtyn2dJDUU6AHUZRGH1A2vglKE=; b=lDAlCJkNf2lnHWYvAIr7AHVYXZEsXRQ30yJLqCWDRo4n7QL9TjGWUGfBpvzTiAIe3xOwiY8J0dF5fjtC/34phMcz3XdE7AKVpTac85en0o+66HJPYY27eF52hIDTa7T8WR/lPwq9PVWjfL+zUIKRWvQ8qx8jxPxg+LZxTrRjMTplMRCbJtSAgyZrXvExbAnTfHNUkOe3CYakItxU4b4LBH5AQBgFgcpXLsAhG/26fXPONEkOAOHD1RtvfYCDpSjFP9EFsGPkCM5Cw78uSHkDmjZateumN1d+CSRtEn7dRzZ6nCTbORyhTMH4pjLRSrX1fF3YTtjUUHeJT///h+zc1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) by BL1PR11MB5543.namprd11.prod.outlook.com (2603:10b6:208:317::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.30; Fri, 14 Apr 2023 09:22:24 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::695b:260c:f397:2b69]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::695b:260c:f397:2b69%4]) with mapi id 15.20.6298.030; Fri, 14 Apr 2023 09:22:24 +0000 Date: Fri, 14 Apr 2023 10:22:17 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= CC: Tyler Retzlaff , , , , Subject: Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC Message-ID: References: <1680558751-17931-1-git-send-email-roretzla@linux.microsoft.com> <1681421163-18578-1-git-send-email-roretzla@linux.microsoft.com> <1681421163-18578-12-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35D87878@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87878@smartserver.smartshare.dk> X-ClientProxiedBy: LO2P265CA0156.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::24) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|BL1PR11MB5543:EE_ X-MS-Office365-Filtering-Correlation-Id: 7d46d619-a30e-4386-47ff-08db3cc9c1d3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fBLnSWgixsOspT6GE0J/imnIEgwlX5ZXfGPd4Ugp42WiQSQ4cYDeIsmglUknTnqGaj4MCawWJKu9I+tiMGy2Qj7v31Z1LmzEkxtz5WQzIuf+X+tpoDKKV3OeO4FTFjERAvnZ5qMENdT6AMJIAjnJlF8p7hGEqHwJYNawAYO/xTYSSnPLTgkfNMi8ecyO4tzGDRXi9eP1BYBJsInrgWqIBGPiqIJNNvR5v6sdnAzAHmCROde46HR5kHrpwVVk8OuxTlaGeLlDXLZR77jY+Cbr8q8rId+tBE/JTrIShTCw9PCBci1Sb7v/l+BOAt7A2IIEy/jSOMwcbBDBQYy094WLlaYVZBKd0tCM/ky6MyG6SWzpRVvd3mc+AfexVbUgvvix5O6uHtPKS+CsRV4IDp7Hx7b0V3H0o2ft0LbPcCuiKu/MLK0T/zOnh6aA1MgbBxiSArs6yvwr6Pya3KUY5aElg6FI/t14VBKY5+e+BeHcDP+Bdi4PDHXhxTM2vE5I9XjjkS2v3t2qqNjNlOYscUrugail4dfHyoUx11vNcI6RtJlUi42vlAiIY+SKwir5TWjG6DdNn/UNHdGDfkUMgpX4QEZiChJoJRqtGEHmtVXO/MI= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(366004)(376002)(136003)(396003)(346002)(39860400002)(451199021)(66556008)(6916009)(316002)(4326008)(66574015)(83380400001)(66946007)(6486002)(66476007)(478600001)(8676002)(8936002)(82960400001)(41300700001)(38100700002)(6666004)(44832011)(5660300002)(2906002)(6506007)(26005)(186003)(6512007)(86362001)(67856001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?/zeR4CB/IgLmeGrp7ToTcCiDqS4WAThrB+pT4WMyoBBRV6zfSakxw/iywv?= =?iso-8859-1?Q?ftkYaJfX2LclK+UfBKYmgVUM191Jiqbx5e3lHSlAVcnfbCHi95eSJnq/mn?= =?iso-8859-1?Q?QLRX/T5bLsK06NDoRgB7O+SJ34QcR8b44el6n5Nk2efZ84PC3FC5QkaV6H?= =?iso-8859-1?Q?RZHzPzBgp8UBn1q7IBMVpYSvT70P4S71CNEbAnUpfF/4w1BlwuwyBFABXt?= =?iso-8859-1?Q?K+ye6e68aO4loQqeCht/RzFbyMLv+sXz/M3aXOltHBlZ1ieJ4J3gzfS0Du?= =?iso-8859-1?Q?aZ+PMXijd2WM+Lv8TtXKA8p4IRT5ybsTKdtd72jRmSiqEB1dbrL+Ei3gos?= =?iso-8859-1?Q?azFrRBPX7cKErP341Tf2k+hjXAI9tFjAAq6s/TvmihTRIYE1qYTEu9lGws?= =?iso-8859-1?Q?P8N3gGvmjRL96G3pdAGwaWdEiBqxuh2PIgfii3Lp+c/q6gHSq62VcLrEU0?= =?iso-8859-1?Q?gP97DM6iqI1nvbGmZiPtQkR02h6sYYDxciBYPGwnH0YjK3A45fJikmez+f?= =?iso-8859-1?Q?SipupZFT82yI94h8cTvJmgmvvAKtMx9DzTw6NTP5y+JGL9yGbNfnXiH3l8?= =?iso-8859-1?Q?VeCs0HSoWDOVgsTANMrJdq+DxAtZQojfz8rt3ctzaMesqxujWV+C9BHRpH?= =?iso-8859-1?Q?RoWenpRDMxbzTtjfQE3JhXuYBEvV9Iol0mKcOsgQVoiy/oi3pHuY6Z63ix?= =?iso-8859-1?Q?kvDQky6GCwT3PDUt8m0CitakuE1SBp6GYy7FS+98bAdN2SqWObuKoiU6d8?= =?iso-8859-1?Q?ak/DjIeGl4E3HzcWHnySlde/wb1wmWX7fTd1s+nD6NRWs66Q0Jpwyk9Sde?= =?iso-8859-1?Q?R3KQvOyuvgmeVlOQUYGZ3JKLinG9A5+tCJY7mDcTlgBbZjFD30mt2oZejy?= =?iso-8859-1?Q?6Yq2+YPbzgrWcV7ZGNKkL3xDkfzatBM7KN/0oPLmneqqd+f/wUIwj8Zfsv?= =?iso-8859-1?Q?7eVIepdBZs7BXVLrNRtb5zOUCwI8Ih4GP6QRjy08XDQ9cDJVWp2Zh5hZuG?= =?iso-8859-1?Q?ZtJpeHMpnfkiez5sV4ucTwBHo9Nw0o+oZ/P+RELERrbpTuYPIwvzcTL6qo?= =?iso-8859-1?Q?V0t+dgcgYwPIBDiDnTQSg3kOYFkTVqlrMCYbN7f6oNMdm5IMtdwqgJdjh6?= =?iso-8859-1?Q?HzGPAIhz5Yo8WAdGuhxFFf6wOPptaZZsaJqmjcdH6g7pRR/0M/cLTP2dy+?= =?iso-8859-1?Q?RtHedEnmMTbb2qsIX4DOmo3QmNSRHVoKBFTB5B9MNlQ9G9QHHIMnERiCl8?= =?iso-8859-1?Q?QfPPausY3zAT9ByK7klLtFz42GYSz87kVbWsNNCFfricF6Aym2P4S4tCGg?= =?iso-8859-1?Q?jhNVxzplI1elkxhhwebH+WYLNiN938rqPXh7tWQ8Ee2xw4tnQHJWrrqGpQ?= =?iso-8859-1?Q?Ps/7vDNvnE6c2P8fi4Q0PPbBGsu8TGJIaVglMHB2wftTufHMR6N3LzcXi3?= =?iso-8859-1?Q?ytF5z3SDJzZH/nrf5F0gX33J+Qa/x8FiA4N3Xqf9x42IpE7WuQuES8sqM0?= =?iso-8859-1?Q?AXw5+MSpRu+EH8T9K5ftD1BKoLx/YkjylEqOnSB5DQ23FPF/W+YHc0DqFP?= =?iso-8859-1?Q?icpco4Uvj2nMbAV77AhDhu09dNv1MR03qDQUZ2leU2tWxfPfRpZH5nIjwZ?= =?iso-8859-1?Q?VhD6ui5p2jZnjyxX6lE2eFWdGxKhBCfmM4igPco4ne78GGDDO/Wyy1ZQ?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 7d46d619-a30e-4386-47ff-08db3cc9c1d3 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2023 09:22:24.4264 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: luLsC42k1VLGZp/ADaPkrVP84hqnkz9+aa0sCASzhjnWEpqcxiKCQ6r2vnHQXkp4Qw/5dh4qasQYbClo5qJxooBtZQFy9kcm9p13soizG+E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5543 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Apr 14, 2023 at 08:45:17AM +0200, Morten Brørup wrote: > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Thursday, 13 April 2023 23.26 > > > > For now expand a lot of common rte macros empty. The catch here is we > > need to test that most of the macros do what they should but at the same > > time they are blocking work needed to bootstrap of the unit tests. > > > > Later we will return and provide (where possible) expansions that work > > correctly for msvc and where not possible provide some alternate macros > > to achieve the same outcome. > > > > Signed-off-by: Tyler Retzlaff > > --- > > lib/eal/include/rte_branch_prediction.h | 8 ++++++ > > lib/eal/include/rte_common.h | 45 > > +++++++++++++++++++++++++++++++++ > > lib/eal/include/rte_compat.h | 20 +++++++++++++++ > > 3 files changed, 73 insertions(+) > > > > diff --git a/lib/eal/include/rte_branch_prediction.h > > b/lib/eal/include/rte_branch_prediction.h > > index 0256a9d..d9a0224 100644 > > --- a/lib/eal/include/rte_branch_prediction.h > > +++ b/lib/eal/include/rte_branch_prediction.h > > @@ -25,7 +25,11 @@ > > * > > */ > > #ifndef likely > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define likely(x) __builtin_expect(!!(x), 1) > > +#else > > +#define likely(x) (x) > > This must be (!!(x)), because x may be non-Boolean, e.g. likely(n & 0x10), and likely() must return Boolean (0 or 1). > Will this really make a difference? Is there somewhere likely/unlikely would be used where we would not get the same conversion to boolean than we get using "!!" operator. [NOTE: Not saying we shouldn't put in the !!, just wondering if there are actual cases where it affects the output?] > > +#endif > > #endif /* likely */ > > > > /** > > @@ -39,7 +43,11 @@ > > * > > */ > > #ifndef unlikely > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define unlikely(x) __builtin_expect(!!(x), 0) > > +#else > > +#define unlikely(x) (x) > > This must also be (!!(x)), for the same reason as above. > > > +#endif > > #endif /* unlikely */ > > > > #ifdef __cplusplus > > diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h > > index 2f464e3..1bdaa2d 100644 > > --- a/lib/eal/include/rte_common.h > > +++ b/lib/eal/include/rte_common.h > > @@ -65,7 +65,11 @@ > > /** > > * Force alignment > > */ > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define __rte_aligned(a) __attribute__((__aligned__(a))) > > +#else > > +#define __rte_aligned(a) > > +#endif > > It should be reviewed that __rte_aligned() is only used for optimization purposes, and is not required for DPDK to function properly. > Good point. If we look across all of DPDK, things will likely break, as we are relying on alignment in various places to use the aligned versions of instructions. For example _mm256_load_si256() vs _mm256_loadu_si256() in our x86 vectorized driver code. A "git grep _load_si" shows quite a few aligned vector load instructions used in our codebase. These will fault and cause a crash if the data is not properly aligned. [I suspect that there are similar restrictions on other architectures too, just not familiar with their intrinsics to check.] However, it may be that none of the code paths where these are used is in code currently compiled on windows, so this may be safe for now. The occurances are mostly in drivers. $ git grep -l _load_si drivers/common/idpf/idpf_common_rxtx_avx512.c drivers/event/dlb2/dlb2.c drivers/net/bnxt/bnxt_rxtx_vec_avx2.c drivers/net/bnxt/bnxt_rxtx_vec_sse.c drivers/net/enic/enic_rxtx_vec_avx2.c drivers/net/i40e/i40e_rxtx_vec_avx2.c drivers/net/i40e/i40e_rxtx_vec_avx512.c drivers/net/iavf/iavf_rxtx_vec_avx2.c drivers/net/iavf/iavf_rxtx_vec_avx512.c drivers/net/iavf/iavf_rxtx_vec_sse.c drivers/net/ice/ice_rxtx_vec_avx2.c drivers/net/ice/ice_rxtx_vec_avx512.c drivers/net/ice/ice_rxtx_vec_sse.c drivers/net/mlx5/mlx5_rxtx_vec_sse.h lib/acl/acl_bld.c lib/distributor/rte_distributor_match_sse.c lib/efd/rte_efd_x86.h lib/hash/rte_cuckoo_hash.c lib/member/rte_member_x86.h lib/net/net_crc_avx512.c lib/net/net_crc_sse.c > > > > #ifdef RTE_ARCH_STRICT_ALIGN > > typedef uint64_t unaligned_uint64_t __rte_aligned(1); > > @@ -80,16 +84,29 @@ > > /** > > * Force a structure to be packed > > */ > > +#ifndef RTE_TOOLCHAIN_MSVC > > #define __rte_packed __attribute__((__packed__)) > > +#else > > +#define __rte_packed > > +#endif > > Similar comment as for __rte_aligned(); however, I consider it more likely that structure packing is a functional requirement, and not just used for optimization. Based on my experience, it may be used for packing network structures; perhaps not in DPDK itself but maybe in DPDK applications. > +1 Once libraries such as the net library in DPDK will form part of the windows build this will need to be addressed or things will break. > The same risk applies to __rte_aligned(), but with lower probability. > /Bruce