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 61DD9A0547; Fri, 30 Jul 2021 13:10:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 22EC840042; Fri, 30 Jul 2021 13:10:19 +0200 (CEST) Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by mails.dpdk.org (Postfix) with ESMTP id BFE694003F for ; Fri, 30 Jul 2021 13:10:17 +0200 (CEST) Received: by mail-wr1-f45.google.com with SMTP id h14so10795600wrx.10 for ; Fri, 30 Jul 2021 04:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=f8aigFzvJ85Ys+A6kLriPMgoThsPoCD5INefUlQ38+k=; b=Nf+qS0Ihoacp18bKmBetj7NkQzkO2PlzxJZUwj7mdrz2zYPoqgsStMfe5wQg+UdTd9 DmKUcsjgMYs5Vxigrd0/OTN7CB8pPomscswIN49HZfOEXNCwIOIxHDD8jfhKwf+AVek9 KmMEOXLejvN4izYlEvyZJkyrzIv+SEQrgDGGq28zmcdQ/5R83NDCQz+fEh9byAKi7exb e4Eny+jqX6mMt3qIswxELzT1fePEeo7Rq4GJ7W4Oink0+kW0PgHmGXlk/ejWnx83UEEb vTV4kkH1LtMQFBRMjR/fVAiwC86Ea2OYb3ydd6ex9PlxOpnVbzT106nM5vIRNhHGNjx1 SA+g== 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:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=f8aigFzvJ85Ys+A6kLriPMgoThsPoCD5INefUlQ38+k=; b=oh/9k/x6//KkgmqmSwnngnO0srGXHL61VFXrCjrgyCEdDs9XnsLUVfpVgpZafZEzy5 YmAmOZzfXUZ0yKH5/oo4wvkjugFhW3BB9EzDqrc5jHQxcle2FfU+IHZUpllmUkl2UA4X oq1nwdNGtzWHEKs3kXY5LZq6oidhEKn6bEXzRP3V0uunB27fz0CdICfBgAELQDbBMT8J 5Zl7LcJZfp3irxxRAgQozzQrNPbGVMesQ9JAbS1he2hQqF0lJ8V/uV8buO/sSEAR6vjg biULJFvkbPYTKXX3cAqRsXU8eP4JMtnc6zpHzHBHHCLtZzfYz4GyES0kMKBfzpPLb3VW s9fA== X-Gm-Message-State: AOAM532wSGk1UA1vtc0D6KFRl74W0fx1aJXav6dGf4M/x0V03Uwp44uu 3B7esUZ5p0Q7PBckzezOLI/hsA== X-Google-Smtp-Source: ABdhPJyPGTdX/2jj5p17NSmFFSzgT+F2yFupdAkuc/8rzw3e8UDWLMUW3/LsyBbJpED8igm74E8v4w== X-Received: by 2002:adf:ec10:: with SMTP id x16mr2326778wrn.375.1627643417462; Fri, 30 Jul 2021 04:10:17 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id n11sm1585285wrs.81.2021.07.30.04.10.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 04:10:16 -0700 (PDT) Date: Fri, 30 Jul 2021 13:10:15 +0200 From: Olivier Matz To: Eli Britstein Cc: dev@dpdk.org, Ilya Maximets , Gaetan Rivet , Majd Dibbiny , Asaf Penso , Thomas Monjalon , Harry Van Haaren , stable@dpdk.org, Andrew Rybchenko Message-ID: References: <20210713064910.12793-1-elibr@nvidia.com> <20210713064910.12793-3-elibr@nvidia.com> <045f7d4b-c9dc-0a1e-25c8-359f14dfcc66@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <045f7d4b-c9dc-0a1e-25c8-359f14dfcc66@nvidia.com> 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 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. 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 > > >