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 0CAD246069; Mon, 13 Jan 2025 10:27:54 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C3D2A402A7; Mon, 13 Jan 2025 10:27:53 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 0936C40261 for ; Mon, 13 Jan 2025 10:27:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736760471; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4s9ATuYXnyL+mrYgRCMwOYmBcSUJA3h6z+VBGGuYN0Q=; b=bc7XEgmttZxqjPNJ846c5oTK96Ph9EJRmW1T42ny0G0VNkn32vt0zAKuf5GrkwIQQmrO4g GA1s/JXAwEkRBbrZ9NUZ3XBUM4x5DP1awxyctLFBPGRHyYuZMuYZgO9iyAhzpKskUTtW2s y+U3BWXNaAP/fEBm4Y7k/9EOyqRulLQ= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-610-r_TNyfejOT2MDFYiiRmjQg-1; Mon, 13 Jan 2025 04:27:50 -0500 X-MC-Unique: r_TNyfejOT2MDFYiiRmjQg-1 X-Mimecast-MFC-AGG-ID: r_TNyfejOT2MDFYiiRmjQg Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-302325e576bso17168061fa.2 for ; Mon, 13 Jan 2025 01:27:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736760468; x=1737365268; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4s9ATuYXnyL+mrYgRCMwOYmBcSUJA3h6z+VBGGuYN0Q=; b=N4uTpc8YbVULEK3YWhwvtIwSbr7/8hDAWEmoHMBQYxuMus1B90fVsWBByNj1dl0DuP dBNOYoN3EnENZON9h+Z9s/6Q3bo3FMPFpxhKrVZNwy73M1QNC+pHfuz+6xjauOkgAzNV DN6wvR1ClrxPXCQ5emRwWexTwnFhBUyxkbQSmIQAGp97yjTERrYVBCHTWNnbE3PuopG0 ZYB/NF9/4PlAi7cVqw+5vxRExQqkGBsJ8/qs5KzHgjcwCLasW70mtZSWqTiEY/5mId1l oyeDxGLBrSklW1kEw9VGXS/CIlRGEvTk20uBeDCL+jV7JWt4k7SzB9BNdOVIFkC/jC2B Pw7Q== X-Gm-Message-State: AOJu0YyyRsnfMMBOV7erMdFGFCO0zluL8U2QQXDgPQzCCVzPX38YM23u ZezW/XQYsTNlbL2ZafR0q5xadhWpQSoYzneOCwcbdVFYDcxwbRsF+wJA+HVDsJAAdwni1xleVIJ k+DwZvdE26pINNWbBzdEP59uZDePuWNCcMf2sdq2H3p35p8KUqG6A9IaoxLv2aEzD0zkkGCKG0M PYIvEXkl+dviI4IdQEbasrqoM= X-Gm-Gg: ASbGnculCCxzR514jmBJL/g4G7bkjtA9Af7bCT6R9Ma2UL3FKPaeDMHl/59CQdH78Ut eGvPgUz/3nfUakrD2eTfCScoMmlmx3Quaxg1Mw5fn X-Received: by 2002:a05:651c:1a0c:b0:302:1cdd:73c6 with SMTP id 38308e7fff4ca-305f456851fmr62264081fa.20.1736760468282; Mon, 13 Jan 2025 01:27:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IHzRcesJNbg+TBpuMHQZaVUxW0djpeBAvC/tTkEZiN6xqb1bUQp/4FatTk8RKbzeZWxTQjY8JrpZs1TDVPNBUg= X-Received: by 2002:a05:651c:1a0c:b0:302:1cdd:73c6 with SMTP id 38308e7fff4ca-305f456851fmr62264001fa.20.1736760467890; Mon, 13 Jan 2025 01:27:47 -0800 (PST) MIME-Version: 1.0 References: <1710968771-16435-1-git-send-email-roretzla@linux.microsoft.com> <1736547411-5895-1-git-send-email-andremue@linux.microsoft.com> In-Reply-To: <1736547411-5895-1-git-send-email-andremue@linux.microsoft.com> From: David Marchand Date: Mon, 13 Jan 2025 10:27:36 +0100 X-Gm-Features: AbW1kvbYMDvl2r6BYxL5mtXSSqON8ETaiGEwYU8cBvePAaFpHsGlxVx66oKQWjc Message-ID: Subject: Re: [PATCH v11 00/30] fix packing of structs when building with MSVC To: dev@dpdk.org Cc: roretzla@linux.microsoft.com, aman.deep.singh@intel.com, anatoly.burakov@intel.com, bruce.richardson@intel.com, byron.marohn@intel.com, conor.walsh@intel.com, cristian.dumitrescu@intel.com, david.hunt@intel.com, dsosnowski@nvidia.com, gakhil@marvell.com, jerinj@marvell.com, jingjing.wu@intel.com, kirill.rybalchenko@intel.com, konstantin.v.ananyev@yandex.ru, matan@nvidia.com, mb@smartsharesystems.com, orika@nvidia.com, radu.nicolau@intel.com, ruifeng.wang@arm.com, sameh.gobriel@intel.com, sivaprasad.tummala@amd.com, skori@marvell.com, stephen@networkplumber.org, suanmingm@nvidia.com, vattunuru@marvell.com, viacheslavo@nvidia.com, vladimir.medvedkin@intel.com, yipeng1.wang@intel.com, Andre Muezerie X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 2bP2uH7hoz-YW_OAbfABLt27--6--cGJSAUhCd0nw4g_1736760469 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Jan 10, 2025 at 11:17=E2=80=AFPM Andre Muezerie wrote: > > MSVC struct packing is not compatible with GCC. Different alternatives > were considered: > > 1) Have a macro __RTE_PACKED(decl) to which the struct/union is passed > and the macro would define the struct/union with the appropriate > packing attribute for the compiler in use. > > Advantages: > * Can be placed in front of a struct, or even in the middle. Good > for readability. > * Does not require a different macro to be placed at the end of the > structure. > > However, problems can arise when compiler directives are present in the > struct, as they become arguments for __RTE_PACKED macro. This is not > portable. Two problematic situations observed in the DPDK code: > > a) #defines mentioned in the struct. In this situation we could just > move the #define out of the struct. > > b) #if/#ifdef/#elif mentioned in the struct. > This is a somewhat common pattern in structs where fields change > based on endianness and would require code duplication to be > handled, which makes the code hard to read and maintain. > > 2) Have macros __rte_msvc_pack_begin and __rte_msvc_pack_end which > would be placed at the beginning and end of the struct/union > respectively. Concerns were raised about having macros for > specific compilers, or even having compiler names mentioned in > the macros' names. > > 3) Instead of providing macros exclusively for MSVC and for GCC, > have a macro __rte_packed_begin and __rte_packed_end which would > be placed at the beginning and end of the struct/union respectively. > With MSVC both macros end up having a purpose. With GCC and Clang > only __rte_packed_end has a purpose, as can be seen below. > This makes the solution generic and is the approach taken in this > patchset. > > #ifdef RTE_TOOLCHAIN_MSVC > #define __rte_packed_begin __pragma(pack(push, 1)) > #define __rte_packed_end __pragma(pack(pop)) > #else > #define __rte_packed_begin > #define __rte_packed_end __attribute__((__packed__)) > #endif > > Macro __rte_packed_end is deliberately utilized to trigger a > MSVC compiler warning if no existing packing has been pushed allowing > easy identification of locations where the __rte_packed_begin is > missing. > > Macro __rte_packed is marked deprecated and the two new macros represent > the new way to enable packing in the DPDK code. > > Script checkpatches.sh was enhanced to ensure that: > * __rte_packed_begin and __rte_packed_end show up in pairs. > * __rte_packed_begin is not used with enums. > * __rte_packed_begin is only used after struct, union, > __rte_cache_aligned, __rte_cache_min_aligned or __rte_aligned Recheck-request: ci/iol-marvell-Functional --=20 David Marchand