Tal, See attached compiler bug section for details. -----Original Message----- From: Omar Cardona Sent: Wednesday, May 13, 2020 1:04 AM To: Tal Shnaiderman <tal...@mellanox.com>; Dmitry Kozlyuk <dmitry.kozl...@gmail.com>; Thomas Monjalon <tho...@monjalon.net>; pallavi.ka...@intel.com; navas...@linux.microsoft.com; ranjit.me...@intel.com; Harini Ramakrishnan <harini.ramakrish...@microsoft.com>; Dmitry Malloy (MESHCHANINOV) <dmit...@microsoft.com>; Yohad Tor <yoh...@mellanox.com>; Jie Zhou <j...@microsoft.com> Cc: dev@dpdk.org Subject: RE: rte_mbuf structure size in Windows
IIRC, it's this issue. https://bugs.llvm.org/show_bug.cgi?id=24383 -----Original Message----- From: Tal Shnaiderman <tal...@mellanox.com> Sent: Wednesday, May 13, 2020 12:55 AM To: Dmitry Kozlyuk <dmitry.kozl...@gmail.com>; Thomas Monjalon <tho...@monjalon.net>; pallavi.ka...@intel.com; navas...@linux.microsoft.com; ranjit.me...@intel.com; Harini Ramakrishnan <harini.ramakrish...@microsoft.com>; Omar Cardona <ocard...@microsoft.com>; Dmitry Malloy (MESHCHANINOV) <dmit...@microsoft.com>; Yohad Tor <yoh...@mellanox.com> Cc: dev@dpdk.org Subject: [EXTERNAL] rte_mbuf structure size in Windows Hi, I've noticed that there is a difference between the size of rte_mbuf in a Unix build comparing to Windows. The requirements is for rte_mbuf is to be RTE_CACHE_LINE_MIN_SIZE * 2 bytes however when I'm building it in Windows the size is RTE_CACHE_LINE_MIN_SIZE * 3. Looks like the diff results from the usage of bit fields inside rte_mbuf, from my testing it looks to me like the usage of 2 different bit fielded types inside rte_mbuf causes additional padding in Windows. For example from rte_mbuf, the following unions have the same size in Windows and Linux: union { uint32_t packet_type; // bit fields of type uint32_t will follow ... };... 4 bytes both in Unix and Windows. union { uint64_t tx_offload; // bit fields of type uint64_t will follow ... }; 8 bytes both in Unix and Windows. However when creating a struct containing both unions I'm getting sizeof 16 bytes in Unix and 24 bytes in Windows. Did someone faced this issue before? Is this a result of different alignment between gcc and clang when bit fields are used? Thanks, Tal
