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 59EBB45463; Sat, 15 Jun 2024 18:04:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43D55402DF; Sat, 15 Jun 2024 18:04:47 +0200 (CEST) Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by mails.dpdk.org (Postfix) with ESMTP id C611A402C3 for <dev@dpdk.org>; Sat, 15 Jun 2024 18:04:45 +0200 (CEST) Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-2c2dee9d9cfso2787982a91.3 for <dev@dpdk.org>; Sat, 15 Jun 2024 09:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1718467485; x=1719072285; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=dFmQ0uiM6J250relRBbbnxNBlLxSPDX5CB/+/TWkWSM=; b=zvemIWzSQgXuzQlHfuipT78RQGkelqxWIiK1/wDswYpOPRy7tcD7meoQETvSkOHs35 01nb8dPmiJuRuZd1f+dnzWU+T8Cxau37DNjqf9PEo01UUBXSZTUQqa3HemJC8I/1///k DROZtgn26r1pTSfvT+ItaDUV+K6evfch9iykV6IPikUhKZbHigH9lHK3K2jDtbQhyE/k 9h4p7lTdzpXKc4URzBRKf+XLIoZR+O4P3BYE0xb++au2N35CIBYrsfc6a3aVTF+j/tbV 8t3nlLP9gEtf5oEFjpSVejlgJo6VLqmfgYDranMSn7uVucTRj2Qn+jACIFkJFPMzDiPh X9+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718467485; x=1719072285; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dFmQ0uiM6J250relRBbbnxNBlLxSPDX5CB/+/TWkWSM=; b=T+E7584Pd53nGRqfiEZNAo6a7gFLmwFEbGLfpWlvvmqCypI8iM7CMDiRYLeItEpkfO 3cnCIg0lYu64Px9xg6XWGDILgLn4m0U7NVfy+iQuaGdrocZtO8VYOnRUYjeCAFKWw2C1 kau/c9ZBmvOG3dvPY9o/OSC59go7N1XTlmKWg59lMbJIA9bmSxxL8YJDFnyQkPhwyH/9 kTsOQtk9z/EPrrcJ5WC9iLS8DWMiBGTK4tAODlAwhv4S+5VpoNAGSQHdfnfnQRQwC53Q /as7JwusoL7zHA1Exg7wJUk4xaSQ8/Yl7VgQ1M0SPX34XpTAlTM2XvBoEi0UJUeBYGDb vlLQ== X-Forwarded-Encrypted: i=1; AJvYcCXhMtIJp7zu1LLbq2USGxZzF2teoxNmS452hEaUC8CdJVd0OXj+mb18PASq3691pR7HWWLG4msYwyOGkQU= X-Gm-Message-State: AOJu0YwmtD5Mrfog9NcJNayfXdEzNLq14iF2nsTjs2h2PvP8klOAWhWb fY4SyDu6kANnxQ/sbo8d/COpfBYuaG9C5SKU0+MYiiYlb4XiSxcmAGZ5oMpxEao= X-Google-Smtp-Source: AGHT+IHUxq3IqMSS7NhJSfDv5/Q8Bplls4D6o5fzcYSICrzqtF2lgswRRzTeLN88L0z9CGss2HK8KQ== X-Received: by 2002:a17:90a:d70b:b0:2c2:e0f7:8eba with SMTP id 98e67ed59e1d1-2c4db24bc64mr5987097a91.14.1718467484713; Sat, 15 Jun 2024 09:04:44 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2c4c45abc78sm6026938a91.3.2024.06.15.09.04.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jun 2024 09:04:44 -0700 (PDT) Date: Sat, 15 Jun 2024 09:04:42 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Thomas Monjalon <thomas@monjalon.net> Cc: "Van Haaren, Harry" <harry.van.haaren@intel.com>, dev@dpdk.org, "Richardson, Bruce" <bruce.richardson@intel.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com> Subject: Re: [PATCH] event: fix warning from useless snprintf Message-ID: <20240615090442.6894a894@hermes.local> In-Reply-To: <1864322.ucjEoNaZvj@thomas> References: <20240424034541.134335-1-stephen@networkplumber.org> <PH8PR11MB6803A7987785BE6BA06B7478D7102@PH8PR11MB6803.namprd11.prod.outlook.com> <20240424121059.04fc8b63@hermes.local> <1864322.ucjEoNaZvj@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Sat, 15 Jun 2024 13:43:16 +0200 Thomas Monjalon <thomas@monjalon.net> wrote: > 24/04/2024 21:10, Stephen Hemminger: > > On Wed, 24 Apr 2024 17:12:39 +0000 > > "Van Haaren, Harry" <harry.van.haaren@intel.com> wrote: > > > From: Stephen Hemminger <stephen@networkplumber.org> > > > > "Van Haaren, Harry" <harry.van.haaren@intel.com> wrote: > > > > > > From: Stephen Hemminger <stephen@networkplumber.org> > > > > > > > > > > > > With Gcc-14, this warning is generated: > > > > > > ../drivers/event/sw/sw_evdev.c:263:3: warning: 'snprintf' will always be truncated; > > > > > > specified size is 12, but format string expands to at least 13 [-Wformat-truncation] > > > > > > 263 | snprintf(buf, sizeof(buf), "sw%d_iq_%d_rob", dev_id, i); > > > > > > | ^ > > > > > > > > > > > > Yet the whole printf to the buf is unnecessary. The type string argument > > > > > > has never been implemented, and should just be NULL. Removing the > > > > > > unnecessary snprintf, then means IQ_ROB_NAMESIZE can be removed. > > > > > > > > > > I understand that today the "type" value isn't implemented, but across the DPDK codebase it > > > > > seems like others are filling in "type" to be some debug-useful name/string. If it was added > > > > > in future it'd be nice to have the ROB/IQ memory identified by name, like the rest of DPDK components. > > > > > > > > No, don't bother. This is a case of https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it > > > > > > I agree that YAGNI perhaps applied when designing the APIs, but the "type" parameter is there now... > > > Should we add a guidance of "when reworking code, always pass NULL as the type parameter to rte_malloc functions" somewhere in the programmers guide, to align community with this "pass NULL for type" initiative? > > > > > > <snip> > > > > > > Acked-by: Harry van Haaren <harry.van.haaren@intel.com> > > > > > > > Did look into Mi-Malloc https://github.com/microsoft/mimalloc > > it is fast and more complete and good work with huge pages. > > The way to handle tagging allocations having the library automatically handle it > > based on the place allocation is called from. Having user do it is not that helpful. > > But today we have rte_malloc. > And the type is used in tracing. > I think having a meaningful name from the caller is not a bad idea. > > Ok still useful for tracing, but documentation is incorrect (dump stats doesn't use it), and the type field doesn't need to be passed as argument to heap code.