From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <dev@dpdk.org>; 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 <david.marchand@redhat.com>
Date: Mon, 13 Jan 2025 10:27:36 +0100
X-Gm-Features: AbW1kvbYMDvl2r6BYxL5mtXSSqON8ETaiGEwYU8cBvePAaFpHsGlxVx66oKQWjc
Message-ID: <CAJFAV8whkMvd9ahCMUFQi1DS2F2-p8y0=NeYDMf5WqXLAFVwqA@mail.gmail.com>
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 <andremue@linux.microsoft.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Fri, Jan 10, 2025 at 11:17=E2=80=AFPM Andre Muezerie
<andremue@linux.microsoft.com> 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