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 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 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> <5a8ec545-bc65-ab18-2043-0c27fb027530@nvidia.com> Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 >>>> 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 >>>>>