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 0DE5543F1F; Sat, 27 Apr 2024 00:52:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DF05144095; Sat, 27 Apr 2024 00:52:35 +0200 (CEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by mails.dpdk.org (Postfix) with ESMTP id AE28B4406D for ; Sat, 27 Apr 2024 00:52:32 +0200 (CEST) Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-5ce07cf1e5dso2027543a12.2 for ; Fri, 26 Apr 2024 15:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1714171952; x=1714776752; 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=OfzI//e+DcHTdeFO4fgr+Sfgc+OiroBF8dozKEc0fEQ=; b=C6Gr1+Vay1C7lS8EbcuRIIVmH4gUsM3boQFKHg+kNwn+Xc+ewmHGXF9rn7bCvOHQKM RN2APuChQglsV468DDCHsWlxhHLCFLvp3Zl0UqPslx/cJgHR8pkIfum1p3w0b9Wg3L4E MJY73xeegbhLUJEYFMrKK6m4o0wB9b9iNqUnYOMEJPzBEiui92h78VQjJom3MQx/HAtM lznGiLySfcpvlrRJATqp8pzWeRWMays/jvnTWnjHaG89Dl7YWs/STVscJY0pZDboyE43 zOqc4csCY7jd65OzbSPQBIuUz1q2+WSPrz5CZEvUqUk3oW7kFnxTAZmPtP9+dLmL9yVt 4Bdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714171952; x=1714776752; 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=OfzI//e+DcHTdeFO4fgr+Sfgc+OiroBF8dozKEc0fEQ=; b=Rph/uAF1yz5jatecl31vUYXo3iuSQ4a0WyK3BiNgSrsdbnjZU7MOwwZcIgCBoUaUAQ GG4pv1/rndWzYy04uw5c0CNhMCOJpASmuGJUVfZFahQ+4YTItt4jXjtX+is6k35qXFaA iHdx5RbHsHQoTxLuPzTsFqPHPGoEMq9Yxvct3fNULhQSfL1w4z6u41A16z3uvFhyXvQM UQFZBAOjdhOvRX9q3eooMpUAZ6eFDFXqHLhSt17eBTY+ulvwkm3hew6nkXzJ4daBIRQ6 O2nxVF/BWKsN4Res0iz01uoNAGisCSxloSxW4H2iZiztbUg7xDegOIqVm0yk+qVOFkiz 6Yag== X-Gm-Message-State: AOJu0YwPBR7ycII9smh/l+tCxC2n3wEmmEm+WNpGqGDTRFYwsk7w8VCl 6VK3I9WX3z9Bge1j31u75wyRC7Zl1CCWTqCRxvpOI4OUt9KTCKkkdUAoTRlE1EI= X-Google-Smtp-Source: AGHT+IFpAmzJZ1IXRGeVjxT7gE/1YXd4ByZ1nur6nAFb874e7LudQsQZjrEabmvRTj6XPoxBY1st7w== X-Received: by 2002:a17:902:784f:b0:1e2:a31e:2062 with SMTP id e15-20020a170902784f00b001e2a31e2062mr4057395pln.53.1714171951552; Fri, 26 Apr 2024 15:52:31 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id c8-20020a170902724800b001e2a42a2e34sm15915152pll.65.2024.04.26.15.52.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Apr 2024 15:52:31 -0700 (PDT) Date: Fri, 26 Apr 2024 15:52:29 -0700 From: Stephen Hemminger To: Tyler Retzlaff Cc: dev@dpdk.org Subject: Re: [RFC 4/4] eal/malloc: remove type argument from internal malloc routines Message-ID: <20240426155229.68bfc50f@hermes.local> In-Reply-To: <20240426161627.GA29409@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240425182738.4771-1-stephen@networkplumber.org> <20240425182738.4771-5-stephen@networkplumber.org> <20240426161627.GA29409@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, 26 Apr 2024 09:16:27 -0700 Tyler Retzlaff wrote: > > > > diff --git a/lib/eal/common/eal_common_memzone.c b/lib/eal/common/eal_common_memzone.c > > index 32e6b78f87..2d9b6aa3e3 100644 > > --- a/lib/eal/common/eal_common_memzone.c > > +++ b/lib/eal/common/eal_common_memzone.c > > @@ -191,14 +191,12 @@ memzone_reserve_aligned_thread_unsafe(const char *name, size_t len, > > if (len == 0 && bound == 0) { > > /* no size constraints were placed, so use malloc elem len */ > > requested_len = 0; > > - mz_addr = malloc_heap_alloc_biggest(NULL, socket_id, flags, > > - align, contig); > > + mz_addr = malloc_heap_alloc_biggest(socket_id, flags, align, contig); > > i may have missed if this was discussed already. for the public api i > understand for now we need to keep the unused parameter in the function > signatures but for internal api/functions i would prefer the parameter > be removed entirely. > > also somewhat related side-note i don't think msvc has a way of marking > function parameters unused as is done with __rte_unused. currently i > expand the macro empty and suppress the warning globally which is not > great. I dropped the parameter from all the internal routines. Are you suggesting having an different name/version for use internally?