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 973554296E; Mon, 17 Apr 2023 17:16:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6AFD240DFB; Mon, 17 Apr 2023 17:16:36 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 84CED40698 for ; Mon, 17 Apr 2023 17:16:34 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 8723C21C1E67; Mon, 17 Apr 2023 08:16:33 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8723C21C1E67 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1681744593; bh=bPgXxsZ9WI8AkgGWI8kU7W7+rfee5B4HG71WT/5v/9k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h6/FlPejLvlNDwdE2l1r4xEfWeHQIGJbxtZ4QYXjZRiqrGaJRjHVoQ2bcwy6hgeRw 6PMTk11psH4LNPaN6yS/ppAf6R/psQBkuDs1SGQbahSLOqFBDcKb8Gw/Ar0RVbfwe5 OdTFZCzuJE3JbHmbSAugLI5SENWoRYK8KgXApUdI= Date: Mon, 17 Apr 2023 08:16:33 -0700 From: Tyler Retzlaff To: Stephen Hemminger Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , bruce.richardson@intel.com, david.marchand@redhat.com, thomas@monjalon.net, konstantin.ananyev@huawei.com, dev@dpdk.org Subject: Re: [PATCH v5 11/14] eal: expand most macros to empty when using MSVC Message-ID: <20230417151633.GB31948@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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> <20230414170226.GA10264@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D8787D@smartserver.smartshare.dk> <20230415205226.GA9699@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D87880@smartserver.smartshare.dk> <20230415155227.28e647a2@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230415155227.28e647a2@hermes.local> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Sat, Apr 15, 2023 at 03:52:27PM -0700, Stephen Hemminger wrote: > On Sun, 16 Apr 2023 00:41:54 +0200 > Morten Brørup wrote: > > > > > > > > /** > > > > > > > * Force a structure to be packed > > > > > > > */ > > > > > > > +#ifndef RTE_TOOLCHAIN_MSVC > > > > > > > #define __rte_packed __attribute__((__packed__)) > > > > > > > +#else > > > > > > > +#define __rte_packed > > > > > > > +#endif > > Could there be cases this gets used for protocol headers or interacting with > HW memory map, And if not packed then the code will not function correctly? yes, that's one of the valid / correct use cases and it can't be avoided if the structs are nested in recursively composed layout. there are a few instances where we don't need compiler generated static-stride. that is we don't need to force packing to get sizeof(T) == offsetof(T.lastfield) + sizeof(T.lastfield). anyway, this is more of an evaluate on a case by case basis for candidates that aren't needed. ty