From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 5DC4CA034F;
Wed, 13 May 2020 10:35:43 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id B57B31D14E;
Wed, 13 May 2020 10:35:42 +0200 (CEST)
Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com
[209.85.167.65]) by dpdk.org (Postfix) with ESMTP id 9D52C1C23C
for <dev@dpdk.org>; Wed, 13 May 2020 10:35:41 +0200 (CEST)
Received: by mail-lf1-f65.google.com with SMTP id z22so12942146lfd.0
for <dev@dpdk.org>; Wed, 13 May 2020 01:35:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=0+Wp6195vHQiH0e4Pujbm++R0SNoissMoZ8uNBvnhOc=;
b=i1pm5FYV9ZA98UE3wrzFld9l5bJArbVODsTUNWYtziTmB/J+gNpIHmwrfrV0yon7Oh
uK2ERmFZI3EJANcRY8f9CezlTqlbdbctfQQzvgMK+e48+qJrm7YVxsiAZdakMrSThTCK
ZfXVe3wYvWXasDLi56YnYa7opxiZ//R+RSdlfUkCbM9x14Ro7hRKjpcqeE4lIgRwN2qC
sOeIp3DC7da07xGv9AskhASgYD+Ov4DlIH2jPY6u4+d7pEApdnNQNL1ESz6nrs0BOBM5
da9sj7Q5A5SFNk/0/p9PebdEBGZBl17TIoYNh8Tse6ucGYuUtVek1T5/fcvCX3s2AiPd
Fqug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=0+Wp6195vHQiH0e4Pujbm++R0SNoissMoZ8uNBvnhOc=;
b=a8X+llvEV18DiTc2GIewcVxeCzMu29HjOm307H/GSAe2ix0tQX6RTxxkVDNZZUKlcs
GidOq0ZegZ/M+BvpMt2lJ71NhL4Re/sNVQh+d8xNh7nDAFhEs7dOdrdN8PjT7rMoIXEa
wCwH1Y5W1Yw1jnSMryQpal5oZ8YA13DeGVp/2fekgRTWI+e5nSNL48aiuho/3+NXOwBs
wJLCP0IoC+kT5t8SDQZneLV9tbkbojbqJVGgPE53LywRAaqFBwDe7R2tMLfMnso1a+R7
F3zt/JxFZAUMkqVEAoG37nxRI31qFwochgJcnR4YVeKu9XAZj9GmrnEPDILpp5AX+u+Y
RRhw==
X-Gm-Message-State: AOAM531H9HQeKP8KWmAnJwbAlFStjKGx/qGvzu1H+ArKaf8ffAN4JEpa
VW5Fi+yNV3SMdtoEy80CSpE=
X-Google-Smtp-Source: ABdhPJxkK3RslfyuOuzyyUu6bXyAlwoQGA5fO8brWLoTlcNdqeQOlEyeiqx7NPUIP9qaSmux+oG6ew==
X-Received: by 2002:a05:6512:3136:: with SMTP id
p22mr17199924lfd.159.1589358941099;
Wed, 13 May 2020 01:35:41 -0700 (PDT)
Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru.
[37.110.65.23])
by smtp.gmail.com with ESMTPSA id j24sm14132271ljg.60.2020.05.13.01.35.40
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 13 May 2020 01:35:40 -0700 (PDT)
Date: Wed, 13 May 2020 11:35:39 +0300
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Tal Shnaiderman <talshn@mellanox.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, "pallavi.kadam@intel.com"
<pallavi.kadam@intel.com>, "navasile@linux.microsoft.com"
<navasile@linux.microsoft.com>, "ranjit.menon@intel.com"
<ranjit.menon@intel.com>, "harini.ramakrishnan@microsoft.com"
<harini.ramakrishnan@microsoft.com>, "ocardona@microsoft.com"
<ocardona@microsoft.com>, "Dmitry Malloy (MESHCHANINOV)"
<dmitrym@microsoft.com>, Yohad Tor <yohadt@mellanox.com>, "dev@dpdk.org"
<dev@dpdk.org>
Message-ID: <20200513113539.226b1a58@sovereign>
In-Reply-To: <AM0PR05MB531389D7D1BB4F07096F1DF5A9BF0@AM0PR05MB5313.eurprd05.prod.outlook.com>
References: <AM0PR05MB531389D7D1BB4F07096F1DF5A9BF0@AM0PR05MB5313.eurprd05.prod.outlook.com>
X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] rte_mbuf structure size in Windows
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
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
Sender: "dev" <dev-bounces@dpdk.org>
On Wed, 13 May 2020 07:55:07 +0000
Tal Shnaiderman <talshn@mellanox.com> wrote:
> 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?
Hi,
This is the issue we were talking about from the beginning of
year. Microsoft was supposed to track the bug and allocate resources to
fix it if possible. On the last community call, Naty and Omar claimed
there is no noticeable performance impact with l2fwd if mbuf spans 3
cache lines, but DmitryM commented this may depend on cache utilization.
For GCC, the following workaround exists:
https://github.com/PlushBeaver/dpdk/commit/37f052cb18d1d5d425818196d5e1d15a7ada0de0
No workaround for Clang is known, bug URL:
https://bugs.llvm.org/show_bug.cgi?id=24383
--
Dmitry Kozlyuk