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 A04B145955; Tue, 10 Sep 2024 12:56:24 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E202402AB; Tue, 10 Sep 2024 12:56:24 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 337D2400D6 for ; Tue, 10 Sep 2024 12:56:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1725965782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tKb49cZgQuTGxaoadCvVGvX/TERF2pT3aRZ0/FO44oY=; b=D5km23dItOvNseIeloO3V3ruSh2pr1ayqaVKwtliDjd5S3h+9KpEUeBPsk6OSXPBSSywBM zg5m/KdCzSGmiNrUevKaojL1MdlNkJSspIuCf/yQ97iqMbFJ1XWvCw9QRXxfWzyqhIUYBH f7Df4LS7upAV8CPJktZ4z17qAAnSJE0= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-198-sdf0NEpjMPuOlke1AnXBBQ-1; Tue, 10 Sep 2024 06:56:21 -0400 X-MC-Unique: sdf0NEpjMPuOlke1AnXBBQ-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-5365cd47dd8so208463e87.2 for ; Tue, 10 Sep 2024 03:56:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725965780; x=1726570580; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tKb49cZgQuTGxaoadCvVGvX/TERF2pT3aRZ0/FO44oY=; b=KP7+KmSs2bQ/mdAxp9JhE2YiNbSYdGzBO/FWN4qXgY36Kqg8DBno+u4B4a45Dp4J5G eLqgmopNHI+Cg9GD0A9lqZ7HOIFPZuImLlnCYwCLPPG9/f67x44wflvucUpFOY3D0xwu Mtgb2rzHufIgtGk4hH7z2L1l7lW9DWjPUcgtL86ABOJ4pBEK8nXt49knjKax23PcrmlN zIAHzPVlvG1q3F1x7tT7XwvdbUJjKrP7sglQo+U8GOQR0NgRqoCqLR6ObPMNGm+uxnZv z1kIZ6GlNNdsJ+e3rqfBnTzI2Ugb+kHIKTVGdN+ZwEz+UvoNnq9IvNFvGM1D6O0l15Ph Bkuw== X-Gm-Message-State: AOJu0YxAppzKmfCYUeleFAzFKhKJRE2MhgrLuon/oAswQ9z95apqMN9g e9PLQ8bONKZPnv5Ak2Mv6jjT5D/6zkPqOM0NC3KhNuhuaHV+ZK9Ux7hLw8xx9UDBPkYHh/1aE7I kylIDq8YKumXbUYfhkBFBSeClZsi599f4MJL+ChrhjK2GjeMYcZ/DS1ySzrkGovre8XQkxqyMUZ yse+3DBIaQNIxdhMM= X-Received: by 2002:a05:6512:e98:b0:536:52c4:d7d3 with SMTP id 2adb3069b0e04-536587aa7b9mr5692952e87.9.1725965779703; Tue, 10 Sep 2024 03:56:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFfWxJ5P2p90ozJTiVnBCLJAMXQu8e5FFbKzAdxGDz0yRgPpqvCZ7A+OfM83xDSYtUHGhDiwQ/rb3WZySEG4tc= X-Received: by 2002:a05:6512:e98:b0:536:52c4:d7d3 with SMTP id 2adb3069b0e04-536587aa7b9mr5692929e87.9.1725965779063; Tue, 10 Sep 2024 03:56:19 -0700 (PDT) MIME-Version: 1.0 References: <20240907145433.1479091-1-david.marchand@redhat.com> <20240907145433.1479091-12-david.marchand@redhat.com> In-Reply-To: <20240907145433.1479091-12-david.marchand@redhat.com> From: David Marchand Date: Tue, 10 Sep 2024 12:56:07 +0200 Message-ID: Subject: Re: [PATCH 11/11] drivers: use per line logging in helpers To: Harman Kalra , Jerin Jacob Kollanukkaran Cc: dev@dpdk.org, Thomas Monjalon , Ferruh Yigit , Bruce Richardson , Stephen Hemminger X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Sat, Sep 7, 2024 at 4:56=E2=80=AFPM David Marchand wrote: > > Use RTE_LOG_LINE in existing macros that append a \n. > > Signed-off-by: David Marchand > --- [snip] > diff --git a/drivers/net/octeon_ep/otx_ep_common.h b/drivers/net/octeon_e= p/otx_ep_common.h > index 7d5dd91a77..ea9788757e 100644 > --- a/drivers/net/octeon_ep/otx_ep_common.h > +++ b/drivers/net/octeon_ep/otx_ep_common.h > @@ -68,18 +68,18 @@ > #define OTX_CUST_DATA_LEN 0 > > #define otx_ep_info(fmt, args...) \ > - rte_log(RTE_LOG_INFO, otx_net_ep_logtype, \ > - "%s():%u " fmt "\n", \ > + RTE_LOG_LINE(INFO, OTX_NET_EP, \ > + "%s():%u " fmt, \ > __func__, __LINE__, ##args) > > #define otx_ep_err(fmt, args...) \ > - rte_log(RTE_LOG_ERR, otx_net_ep_logtype, \ > - "%s():%u " fmt "\n", \ > + RTE_LOG_LINE(ERR, OTX_NET_EP, \ > + "%s():%u " fmt, \ > __func__, __LINE__, ##args) > > #define otx_ep_dbg(fmt, args...) \ > - rte_log(RTE_LOG_DEBUG, otx_net_ep_logtype, \ > - "%s():%u " fmt "\n", \ > + RTE_LOG_LINE(DEBUG, OTX_NET_EP, \ > + "%s():%u " fmt, \ > __func__, __LINE__, ##args) > > /* IO Access */ I am facing a strange warning with gcc 13 on Fedora 39 when compiler optimisations (O3) are on. Looking at the CI reports, some other versions of gcc seem affected. On the other hand, O0, O1, O2 are fine, at least with my gcc. Here is the warning: ccache cc -Idrivers/libtmp_rte_net_octeon_ep.a.p -Idrivers -I../drivers -Idrivers/net/octeon_ep -I../drivers/net/octeon_ep -Ilib/ethdev -I../lib/ethdev -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/log -I../lib/log -Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev -I../drivers/bus/vdev -fdiagnostics-color=3Dalways -D_FILE_OFFSET_BITS=3D64 -Wall -Winvalid-pch -Wextra -Werror -std=3Dc11 -O3 -include rte_config.h -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -fPIC -march=3Dnative -mrtm -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation -DCC_AVX2_SUPPORT -Wno-strict-aliasing -flax-vector-conversions -DRTE_LOG_DEFAULT_LOGTYPE=3Dpmd.net.octeon_ep -MD -MQ drivers/libtmp_rte_net_octeon_ep.a.p/net_octeon_ep_otx_ep_ethdev.c.o -MF drivers/libtmp_rte_net_octeon_ep.a.p/net_octeon_ep_otx_ep_ethdev.c.o.d -o drivers/libtmp_rte_net_octeon_ep.a.p/net_octeon_ep_otx_ep_ethdev.c.o -c ../drivers/net/octeon_ep/otx_ep_ethdev.c ../drivers/net/octeon_ep/otx_ep_ethdev.c: In function =E2=80=98otx_ep_dev_m= tu_set=E2=80=99: ../drivers/net/octeon_ep/otx_ep_ethdev.c:200:12: error: =E2=80=98devinfo.max_mtu=E2=80=99 may be used uninitialized [-Werror=3Dmaybe-uninitialized] 200 | if (mtu > devinfo.max_mtu) { | ^ ../drivers/net/octeon_ep/otx_ep_ethdev.c:186:33: note: =E2=80=98devinfo.max_mtu=E2=80=99 was declared here 186 | struct rte_eth_dev_info devinfo; | ^~~~~~~ cc1: all warnings being treated as errors ninja: build stopped: subcommand failed. This warning only appears with the last patch of the series. Looking at the code, it seems incorrect, as devinfo.max_mtu is supposed to be initialised in otx_ep_dev_info_get() if this function returns 0. A minimum reproducer is (it can be tested on origin/main): $ git diff diff --git a/drivers/net/octeon_ep/otx_ep_ethdev.c b/drivers/net/octeon_ep/otx_ep_ethdev.c index c4a5a67c79..0a6dbcea0d 100644 --- a/drivers/net/octeon_ep/otx_ep_ethdev.c +++ b/drivers/net/octeon_ep/otx_ep_ethdev.c @@ -135,7 +135,7 @@ otx_ep_dev_info_get(struct rte_eth_dev *eth_dev, max_rx_pktlen =3D otx_ep_mbox_get_max_pkt_len(eth_dev); if (!max_rx_pktlen) { - otx_ep_err("Failed to get Max Rx packet length"); + rte_log(RTE_LOG_ERR, otx_net_ep_logtype, "%u %u\n%.0s", 1, 1, ""); return -EINVAL; } (FYI, the %.0s trick comes from expanding RTE_FMT()) After various tries, it seems hitting this error requires passing (at least) 2 arguments in addition to %.0s in the format string. Another observation is that removing __rte_cold from rte_log() declaration makes the warning go away. I am a bit puzzled, it smells like a compiler (optimisation) bug to me. A workaround is to memset(&devinfo, 0) or call rte_eth_dev_info_get() in otx_ep_dev_mtu_set. But on the other hand we may have a deeper issue with RTE_FMT()... Opinions? --=20 David Marchand