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 155CBA0C51 for ; Sun, 1 Aug 2021 10:06:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 00166410E7; Sun, 1 Aug 2021 10:06:24 +0200 (CEST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2082.outbound.protection.outlook.com [40.107.94.82]) by mails.dpdk.org (Postfix) with ESMTP id 6F49440140; Sun, 1 Aug 2021 10:06:22 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CysJqarVVyDdlz3BqMtNVc0nWuGeEbMn+hz4L+xr245DCeWzYjFPvoECKeKPpirch4YJlb+zJVr+Kv2VMdDRo4/6phIXTlnPID0iUufiEcZ1DVgODbXpK3bRa+lWyf18BIF2XLHkUNkfwr0lo2JMykF2683HMxapOY7Tmb4n0jrLGYOBpZjL1KRYiuVBs8GGhCGUGKnkQzogmv1Q012sJRxMb2gQ1ZmljPa0vsVzfZgUsNML8R0VXinPPtCzt28WHkWdBJlFztYrBNF5+0S/as9gzYCoJoOjg6l5PgEuzk72l0j5CuDXJR8gu12mUal4e2LS7sYmbkFmdEn68x5SXg== 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-SenderADCheck; bh=4QhpomGY/0YSUR1ydgtz88ocff+Smw4nqq8gwzR0lzE=; b=GhgWGSU/J5fD4/Tx3R0QCz/4lE+h8aJR3tnuzCb8YlD5xUN64pye3pdSLb8aSRyKU8J/hGJ2CUl2rf+4K3cyibouPZH2BRq9lMbQ9xG7Qi2fXcG9eYIN+5j2Qo/cgCbs9aDfmH2FhkfAC468KxedJ2b3wXU3H7i2kJxRLfVLxMbOIsHPdRbEzY5iMNbDRgHaZ3wJFWFOThB6UdE3tA57nbqBE85ORPR/1vSsco+bBzd48tdZbTpgB4NvGjcvEj22/Koy0mGf6Zu8Jv1WFSZef4Qac7mv4IPvTbjpQY2Ywea7pRL623XLEA6x0bnaITJEPf13xHaIjRC/4uiNKcRQVg== 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=none 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=4QhpomGY/0YSUR1ydgtz88ocff+Smw4nqq8gwzR0lzE=; b=dry6+HJLp719RMJDY73gWKXo199+sClMAO7c1qapAn1J7nXpivwYjV/ALdOI9axbPdNVeFWKVd+IYPUhzpMuH8EcitJ7Xr9MM0HTTJOxuEszXId8LS49EsbZNsSy3kohANoDrq56wbD9hZ/xFF5t7AHJbUF0LOYXgvd7xiqU2PoHfRG69dauahqllPXfyCWcYKooaXIsBq2z1PCnUOCJBnDHUfrI7pqjREtE4j555BXwOg76kqftsqD2t+v0KO9enRGAEpIZ4d09s90dLdVNHuwhn7VOT5JWzxkemapD3SvmjJktEgpr+kWv97Yfw0xHOMhRkt+kfD8fvePZp2zbvg== Received: from CO2PR04CA0161.namprd04.prod.outlook.com (2603:10b6:104:4::15) by BYAPR12MB2871.namprd12.prod.outlook.com (2603:10b6:a03:13d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.26; Sun, 1 Aug 2021 08:06:20 +0000 Received: from CO1NAM11FT011.eop-nam11.prod.protection.outlook.com (2603:10b6:104:4:cafe::7f) by CO2PR04CA0161.outlook.office365.com (2603:10b6:104:4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.20 via Frontend Transport; Sun, 1 Aug 2021 08:06:20 +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 CO1NAM11FT011.mail.protection.outlook.com (10.13.175.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4373.18 via Frontend Transport; Sun, 1 Aug 2021 08:06:20 +0000 Received: from [172.27.13.188] (172.20.187.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 1 Aug 2021 08:06:16 +0000 To: Olivier Matz CC: , Ilya Maximets , Gaetan Rivet , Majd Dibbiny , Asaf Penso , Thomas Monjalon , Harry Van Haaren , , Andrew Rybchenko References: <20210713064910.12793-1-elibr@nvidia.com> <20210713064910.12793-3-elibr@nvidia.com> <045f7d4b-c9dc-0a1e-25c8-359f14dfcc66@nvidia.com> From: Eli Britstein Message-ID: <5a8ec545-bc65-ab18-2043-0c27fb027530@nvidia.com> Date: Sun, 1 Aug 2021 11:06:14 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: 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: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d03df17b-7248-41a0-d489-08d954c33ef2 X-MS-TrafficTypeDiagnostic: BYAPR12MB2871: X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: 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: IhOpBmU6fk5YWVnAmb0cFXeJC5tyQKBB940Y6qXZty1+B81Q8NwXFvVUQBpT0fAXJ/dLtD1y5DbwEgti0VfN18RsVF3mKXQMHnnoWQ2da/wTxd4VkNF4uwot+WZXQCpSCICrnMgOPN7a62iHPbpyhYkoZxVEcuU9a+2i1PrJCiT/8b+ZLbjZe0lBtbOYjQ2MtQrLiFw02dYWLBWBZOgDhZNX6P1M1OmhbxXlh33qyXvr9y3TF6al2M0hnU+qbrYLKBBCnvpPsK3zkcy9Of4mVY/N4YoeoxYyqzaVS6G4b/R4jas3+46zgOzxDOXllEobulBF7t5d+Z537ipl3S7GG5ZbMShGLNfCzo2GBemCwlSTNVHfsi7NTRhVy6uj1dl2YdhTNQXorG/UObMhKMYr5/m54nbMyNcMYWjr1JFUqGganMQsNf+gIbBV2ibcZ6tnwiiuqVml9flDIgy/U8SVKLDmgvaOXDjzDtvlAhao2ZpzhcrlMnosxSyNgB7Q9AB+j7tBlPgV2x7TbaF5OXUAI/0gHOAsijm9twoxkSV7tZTMTNwbdpBpJRhRDHR9FsQxZPBJVZXlYLa1KyCzjO2dfwOWrRQ909RIUikbTTp8NGUejrQnR4APO616yFwk6EEjEraHwSStKb1cOF5/TWuq72PAF+mph1pobeSJu3jU1x6CYNXo2oxx4lZzOjaQ/WU6I3/hKnvMoSBI0fT9IzP8z5LM67DJ7Wh2Wi2lKrxE2JpSuCTxDi47i7E9KTFNHGkx7+oFQ+YGpsK/rbB6C9p8N6As4cVOyoxy9jm7CBm+1ovpwXoIAj60O8hlx0/yALsf0FIG/oGpJuz4KTFG+ftS0dH5cEuFQno4s2RVOgm7JnCxj0k41FDlmjQqFEOu6HJswKjylBwGIh4G43CjBxcpCC5o8rheDsb2SyElJTME7p6XbBvoV5kUntFCAxoRqq0v 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)(39860400002)(136003)(376002)(346002)(396003)(36840700001)(46966006)(70586007)(2906002)(82740400003)(86362001)(7636003)(336012)(70206006)(966005)(356005)(6916009)(478600001)(83380400001)(53546011)(47076005)(5660300002)(426003)(31686004)(186003)(16526019)(8936002)(2616005)(8676002)(31696002)(4326008)(54906003)(36860700001)(36906005)(26005)(36756003)(82310400003)(316002)(16576012)(2004002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2021 08:06:20.0043 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d03df17b-7248-41a0-d489-08d954c33ef2 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: CO1NAM11FT011.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB2871 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 2/3] mbuf: avoid cast-align warning in pktmbuf mtod offset macro X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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 >>> 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 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 >>>>