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 7308CA0547;
Tue, 19 Oct 2021 08:42:09 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 2BC0040142;
Tue, 19 Oct 2021 08:42:09 +0200 (CEST)
Received: from NAM02-DM3-obe.outbound.protection.outlook.com
(mail-dm3nam07on2054.outbound.protection.outlook.com [40.107.95.54])
by mails.dpdk.org (Postfix) with ESMTP id E6A714003E;
Tue, 19 Oct 2021 08:42:07 +0200 (CEST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=Jhl9GLZ3BRiT48TONWZCYKLlpTHaOuWb3MYfgIY0UQ0kIicMhkTvv0jZI8C2yZ/naMpzFL0YV5bysIdzv/JnSsZAEyh+ewwGni+pqmRLEUhS0L/hYxYxG7EaIt3RpV2kbiPKKKTpHY3OsdWr6aFAJigEvcNy7S35pgROzIKAIwsBoXnUEU44EB2Y5TuyJWOg73Ujjf7tsK8MB4YCflhuWvg6ItYOuw01/hnM9o6lMQRAIdDn/hq++tsgYZEER/mDVRYTsadUOZwpC8fAqE0ITo7aS/bbIP5GUSBJvgE52nwmGu6H3oh36iSgR00IKJJ4yIeW5DBQvDlLLmdpl3rqSQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=O2Ab2z1UFxmTdRNDTNtmGdd+q4SZhRXbu5wdH0saE0A=;
b=BdWYR9jmaMYX2SIpzNqrCZwh3Wm2oC2ch+2HTS0ApUU83lSGZhv/jDmyGPuuDOKJmzB9r39SYuTmZUv25cRoZtM1LU8mZLsaxPxGXr6cMOWCZ+p5NvvDbi1bTct65BCT9ynxmTqk1RsQA6TwyMPxEn3a5kwQsUjiGs/4goUlZx/nJ7hD6igc5OTltrREcmnNzDMgAOT4ffJ/semWE5XUa3iwWbBHYjWznZ3WakbobfUQqGGIPq3ts0Q+ic+4Szk1T9+QgA6kOvzd3+LB8vgOxK+MFf92sBatydrdXWdVS8k+voXTJT6jkYUbzdXBDyFV6rtV+naDgAm8JiCGegixnQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
216.228.112.34) smtp.rcpttodomain=ovn.org smtp.mailfrom=nvidia.com;
dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
header.from=nvidia.com; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com;
s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=O2Ab2z1UFxmTdRNDTNtmGdd+q4SZhRXbu5wdH0saE0A=;
b=NZ+vyGoCG6EY4olnZjgtCtV/uolKigFLjn3ob44iVNy6Yey+FzbqGFGIlhLn90pRuBfjvxM20ds7WKH2b18m2pnCyP5Kes2mHVJdbuBOZyoNHOXJTBRpqtDX3U8yR7JWVXc0N/iL+Kv0wvLNaXWHGlhMiMgD3fHZ6TcSC8KLQczo0kZwchU7iySEGMu7pd1GmFYe0Ix1VlA8hX6cvAwRjG9DtyZYCRln1KX+EAy3olTBLa9vkL6aLWXCtHfEjqG9ctaeus2vaepuvFwwO7KJ2iuXALbLDrRj+89DJhrS7HMT47GVgAsROfYZdNgcV7pTPQIvyUkHE3swHNPS5iqCKg==
Received: from MWHPR11CA0025.namprd11.prod.outlook.com (2603:10b6:300:115::11)
by BN6PR1201MB0161.namprd12.prod.outlook.com (2603:10b6:405:55::22)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Tue, 19 Oct
2021 06:42:06 +0000
Received: from CO1NAM11FT066.eop-nam11.prod.protection.outlook.com
(2603:10b6:300:115:cafe::e6) by MWHPR11CA0025.outlook.office365.com
(2603:10b6:300:115::11) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15 via Frontend
Transport; Tue, 19 Oct 2021 06:42:06 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 216.228.112.34)
smtp.mailfrom=nvidia.com; ovn.org; dkim=none (message not signed)
header.d=none;ovn.org; dmarc=pass action=none header.from=nvidia.com;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
216.228.112.34 as permitted sender) receiver=protection.outlook.com;
client-ip=216.228.112.34; helo=mail.nvidia.com;
Received: from mail.nvidia.com (216.228.112.34) by
CO1NAM11FT066.mail.protection.outlook.com (10.13.175.18) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
15.20.4608.15 via Frontend Transport; Tue, 19 Oct 2021 06:42:05 +0000
Received: from [10.222.162.22] (172.20.187.5) by HQMAIL107.nvidia.com
(172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 19 Oct
2021 06:42:00 +0000
From: Eli Britstein <elibr@nvidia.com>
To: Olivier Matz <olivier.matz@6wind.com>
CC: <dev@dpdk.org>, Ilya Maximets <i.maximets@ovn.org>, Gaetan Rivet
<gaetanr@nvidia.com>, Majd Dibbiny <majd@nvidia.com>, Asaf Penso
<asafp@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>, Harry Van Haaren
<harry.van.haaren@intel.com>, <stable@dpdk.org>, Andrew Rybchenko
<andrew.rybchenko@oktetlabs.ru>
References: <20210713064910.12793-1-elibr@nvidia.com>
<20210713064910.12793-3-elibr@nvidia.com> <YQF3rxG8y3cEz13L@platinum>
<045f7d4b-c9dc-0a1e-25c8-359f14dfcc66@nvidia.com> <YQPeFzx3e3VD0TNJ@platinum>
<5a8ec545-bc65-ab18-2043-0c27fb027530@nvidia.com>
Message-ID: <f0da4a1b-f44b-db15-2d89-7f31f81bde81@nvidia.com>
Date: Tue, 19 Oct 2021 09:41:56 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <5a8ec545-bc65-ab18-2043-0c27fb027530@nvidia.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [172.20.187.5]
X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To
HQMAIL107.nvidia.com (172.20.187.13)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e1282fb8-16dc-4921-875c-08d992cb9102
X-MS-TrafficTypeDiagnostic: BN6PR1201MB0161:
X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr
X-Microsoft-Antispam-PRVS: <BN6PR1201MB016189639BD1E4BE915FADCCD8BD9@BN6PR1201MB0161.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: DoIT+PeapQ3Hi07r4Yqdo8vL5/aRfE2QzsfGiuj+/ry51X/4ES6i4ogQgW0ZIMlGgf1bl99NHEMwY4Jhbp0iwtBV6nV/3iWyf+lhDAmTvGUpp4/6Tg02Kq2gM12sq3KECblZkjlxQUTtl0AnsV5XbzHUw+tlmxe9A18Wr6jILSdTA3KYlDGPp5NIBd2iuSAl2koBEc0B1BN5qDC7kEDvRIJseGvlSpL7zuGUJIR13e55m6K91P+HQQykneEn13bRYiPCnoO6M9EXKKEe6JPbzp+6U9RMJEQZahstLqBF3bIZUkMmth1etMZw1b2rszvd8SKbrZyqvaZR00+DtNVIDhsjXnhzh6aIOov3e0rhNcvCjva+6A6YgzLjzzZMyX5FrmVZXb4db2P/skcFX1MrV6m4t5sWJPssDT/SfcGaQNQmvsnZ5iyPU19qxKSB7bEMkyBl9ssQUkAn+HEZXGBiFISoPj9dJ5zHf2Lmd45GA1Q9Ta2SDG7TlplGBM//WCxvFj3wu29BkdLcgEXeUhqfDqxhzNZVUi/wno0Vjmks0l7yc1WL9EpZHVRpz4KTt74v+L8ZQlv9X3+M9JsVbuBSROwjxw25BIZWj3Jx78PQp6IpIPgLB+nJqX3QbBQPbgOsLcyjxg8QYzbCD8pkwID4eYfT1AZNUwadlbc8ddXPE3Q87Wv3tJj7mAMDBVGrRUf2nZo+2OI6cNPnEEB2djWDwcseMOumkbm990X7tMabxPMeeZiAKnCXkrHccLutp107WSAhxQnpskqGsJgUwHXNdwvreCmTchVqBJejZWj1MGgwUItlSUrsag2wY7f0asvrE+X4Z4XoPVSDRcVr7d5JfA==
X-Forefront-Antispam-Report: CIP:216.228.112.34; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:mail.nvidia.com; PTR:schybrid03.nvidia.com; CAT:NONE;
SFS:(4636009)(36840700001)(46966006)(53546011)(426003)(8936002)(336012)(26005)(8676002)(186003)(16526019)(47076005)(31696002)(70206006)(6916009)(31686004)(356005)(4326008)(82310400003)(70586007)(36756003)(7636003)(2616005)(36906005)(316002)(16576012)(2906002)(966005)(86362001)(83380400001)(54906003)(36860700001)(508600001)(5660300002)(6666004)(2004002)(43740500002);
DIR:OUT; SFP:1101;
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2021 06:42:05.3094 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e1282fb8-16dc-4921-875c-08d992cb9102
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[216.228.112.34];
Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT066.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1201MB0161
Subject: Re: [dpdk-dev] [PATCH 2/3] mbuf: avoid cast-align warning in
pktmbuf mtod offset macro
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
Sender: "dev" <dev-bounces@dpdk.org>
Hi Olivier,
On 8/1/2021 11:06 AM, Eli Britstein wrote:
>
> On 7/30/2021 2:10 PM, Olivier Matz wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> Hi Eli,
>>
>> On Thu, Jul 29, 2021 at 10:13:45AM +0300, Eli Britstein wrote:
>>> On 7/28/2021 6:28 PM, Olivier Matz wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> On Tue, Jul 13, 2021 at 09:49:09AM +0300, Eli Britstein wrote:
>>>>> In rte_pktmbuf_mtod_offset macro, there is a casting from char *
>>>>> to type
>>>>> 't', which may cause cast-align warning when using gcc flags
>>>>> '-Werror -Wcast-align':
>>>>>
>>>>> .../include/rte_mbuf_core.h:723:3: error: cast increases required
>>>>> alignment
>>>>> of target type [-Werror=cast-align]
>>>>> 723 | ((t)((char *)(m)->buf_addr + (m)->data_off + (o)))
>>>>> | ^
>>>>>
>>>>> As the code assumes correct alignment, add first a (void *)
>>>>> casting, to
>>>>> avoid the warning.
>>>>>
>>>>> Fixes: af75078fece3 ("first public release")
>>>>> Cc: stable@dpdk.org
>>>>>
>>>>> Signed-off-by: Eli Britstein <elibr@nvidia.com>
>>>> My initial thinking was that it's the problem of the application: if
>>>> -Werror=cast-align is used, it is up to the application to cast the
>>>> return value of rte_pktmbuf_mtod_offset() to (void *) before
>>>> casting it
>>>> to the network type.
>>>>
>>>> But, if I understand correctly, the problem is not about the
>>>> application
>>>> code itself, but about inlined code in the header files of dpdk
>>>> (i.e. compiling an empty C file that just includes the dpdk headers
>>>> with
>>>> -Werror=cast-align). Is it correct? If yes I think it should be
>>>> highlighted in the commit log.
>>> I think yes, though in this specific patch it is not even an inline
>>> function, but a macro.
>>>
>>> However, I don't have a synthetic application example to show those
>>> warnings, thus didn't put such in the commit msg.
>> For this patch, I think it would be useful to have a way to reproduce
>> the issue first, so we can check whether it is the proper place to fix
>> the problem.
> --- a/examples/l2fwd/Makefile
> +++ b/examples/l2fwd/Makefile
> @@ -22,6 +22,7 @@ static: build/$(APP)-static
> ln -sf $(APP)-static build/$(APP)
>
> PC_FILE := $(shell $(PKGCONF) --path libdpdk 2>/dev/null)
> +CFLAGS += -Wcast-align=strict
> CFLAGS += -O3 $(shell $(PKGCONF) --cflags libdpdk)
>
> gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> make -C examples/l2fwd clean static
To reproduce locally with DPDK only, no need to change any file. Only run:
CFLAGS="-Wcast-align=strict" make V=1 -C examples/l2fwd clean static
How would you like to proceed?
Thanks,
Eli
>
>>
>> To me, it is assumed in the DPDK project that we can mmap a network
>> structure on mbuf data (maybe I'm wrong?). If an external application
>> like OVS wants to use -Werror=cast-align, it has to cast the result of
>> calls to rte_pktmbuf_mtod() family.
>>
>> The only corner cases are DPDK header files which have static inline
>> functions or macro that forces the use of rte_pktmbuf_mtod() family
>> without a cast (like for your patch 1/3), because it cannot be fixed in
>> the external project.
>>
>> I think we have to make our header files compliant to projects that want
>> to use -Werror=cast-align, like we do to make our header files compliant
>> to C++.
>>
>> What you suggest in this patch forces the cast to (void *) for all users
>> of rte_pktmbuf_mtod() family. This could be a problem for projects that
>> want to see these warnings.
>>
>> Would it be possible instead to add a cast in DPDK headers, in inline
>> functions that make use of these mtod functions?
>>
>> Regards,
>> Olivier
>>
>>
>>
>>>> Out of curiosity, how did you find the errors? I mean, is it possible
>>>> that some casts are missing some other headers, or is this patchset
>>>> exhaustive?
>>> Currently OVS-DPDK is compiled only with -Wno-cast-align.
>>>
>>> Following complaint that a recent commit introduced a degradation in
>>> OVS
>>> [1], I compiled OVS without this warning deprecation.
>>> The fixes in OVS are [2] and [3] (already merged). The fixes in DPDK
>>> are in
>>> this patch-set.
>>>
>>> [1]
>>> https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/385084.html
>>> [2]
>>> https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/386278.html
>>> e8cccd3a3589 ("netdev-offload-dpdk: Fix IPv6 rewrite cast-align
>>> warning.")
>>> [3]
>>> https://mail.openvswitch.org/pipermail/ovs-dev/2021-July/386279.html
>>> 1f7f557603a5 ("netdev-offload-dpdk: Fix vxlan vni cast-align
>>> warnings.")
>>>> Thanks,
>>>> Olivier
>>>>
>>>>
>>>>> ---
>>>>> lib/mbuf/rte_mbuf_core.h | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/lib/mbuf/rte_mbuf_core.h b/lib/mbuf/rte_mbuf_core.h
>>>>> index bb38d7f581..dabdeee604 100644
>>>>> --- a/lib/mbuf/rte_mbuf_core.h
>>>>> +++ b/lib/mbuf/rte_mbuf_core.h
>>>>> @@ -720,7 +720,7 @@ struct rte_mbuf_ext_shared_info {
>>>>> * The type to cast the result into.
>>>>> */
>>>>> #define rte_pktmbuf_mtod_offset(m, t, o) \
>>>>> - ((t)((char *)(m)->buf_addr + (m)->data_off + (o)))
>>>>> + ((t)(void *)((char *)(m)->buf_addr + (m)->data_off + (o)))
>>>>>
>>>>> /**
>>>>> * A macro that points to the start of the data in the mbuf.
>>>>> --
>>>>> 2.28.0.2311.g225365fb51
>>>>>