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 EA1F745AE2; Tue, 8 Oct 2024 17:45:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43617410FD; Tue, 8 Oct 2024 17:43:40 +0200 (CEST) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by mails.dpdk.org (Postfix) with ESMTP id 540B8410DF for ; Tue, 8 Oct 2024 17:43:36 +0200 (CEST) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-7e6cbf6cd1dso3811137a12.3 for ; Tue, 08 Oct 2024 08:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728402215; x=1729007015; 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=mCjRpMea1kXebf0kP1PloHdF3hz6gqZLVjaI/dVNArw=; b=rZwxTxIbKBpFuzaQkTlJcQyGxNc0iF3M/Pmzli8XAHgjcnnGKgp88p0+/r4rcBfJqh PNWTS1mI7BIPAGYPVbT5ZmOpLP5xQXy22AOMo2yCC5cqvO2aPhzMR1jYyZlF6fCQZZqt b4eCDfYRpxKyC7HRS/aHw6AKiPSk03SeXwW7aIR97oTCF42azaN+LBzgURcXNt8vssHj E2oS71bnAPqJ9/dmFANQEIg2JV5mDdKbqzwQW082teaXlTu7Sxo9ernN1olfWz/eGxV3 FDOp3nExvYnR/1Fvpfm1T1m9FPoXI+ASPNJAMLJtPRnhtntFCIGPS7G+6zZBW4rzvT9L Gwtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728402215; x=1729007015; 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=mCjRpMea1kXebf0kP1PloHdF3hz6gqZLVjaI/dVNArw=; b=mJiwG4bMBki140EvCLgTEAV007b+GP0J5fMxp8aWRa/K5E6BaoDQNULo49mXiFy2j1 piY5YcipQ9jTlKppU0b9UmF5O7oQqlC/rZIXicy0GGYKbRouxk5Z4YG8i1xWxEdNB0hQ nAE89p1Iqk9HDjpljGW9zvWmwmB6nVCMz81189nXX0vFpieIuxRoa+rP9088BbS7i2GR K28MtMTL2jRXaQfQCZgSJnkmPDbtO83toMCUBuR4zto7UbY7Ti1TUUIv7lyVFawwYBi5 hmyvNms1Da5R9iB10iQVaX9k48ZVLFARNrQI9z44UsOtGZY7ogQTLUf6QwM4Yto0zBwg UWfA== X-Gm-Message-State: AOJu0YzDxqL5YXYzbgLMnDo/jdLORX/0Kd5NN+yDXAwxBRF97h/pDPHz R3lz8KgUrsfzffQ0YOH5cRY0rGl0T91F9yU2Hq8tJlRNs5kNbd5vxAKKF83D3Yw= X-Google-Smtp-Source: AGHT+IHTCF/oHFM5X0rQAibhBWTo2wC1oTZ67nONhfDMR1q4lPVxbLTQ7hRlSQZ9GU65tzTiljGjeA== X-Received: by 2002:a05:6a21:9d83:b0:1d8:a077:4e7f with SMTP id adf61e73a8af0-1d8a0775eecmr1685100637.14.1728402215573; Tue, 08 Oct 2024 08:43:35 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71df0d7d18asm6257263b3a.203.2024.10.08.08.43.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Oct 2024 08:43:35 -0700 (PDT) Date: Tue, 8 Oct 2024 08:43:33 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: , "Tyler Retzlaff" , "Anatoly Burakov" Subject: Re: [PATCH v3 17/18] eal: add function attributes for allocation functions Message-ID: <20241008084333.17f65884@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F790@smartserver.smartshare.dk> References: <20240927204742.546164-1-stephen@networkplumber.org> <20240929154107.62539-1-stephen@networkplumber.org> <20240929154107.62539-18-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35E9F790@smartserver.smartshare.dk> MIME-Version: 1.0 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 Tue, 8 Oct 2024 10:29:23 +0200 Morten Br=C3=B8rup wrote: > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Sunday, 29 September 2024 17.35 > >=20 > > The allocation functions take a alignment argument that > > can be useful to hint the compiler optimizer. > >=20 > > This is supported by Gcc and Clang but only useful with > > Gcc because Clang gives warning if alignment is 0. =20 >=20 > This patch defines and uses __rte_alloc_align(). OK. >=20 > >=20 > > Recent versions of GCC have a malloc attribute that can > > be used to find mismatches between allocation and free; > > the typical problem caught is a pointer allocated with > > rte_malloc() that is then incorrectly freed using free(). =20 >=20 > This patch defines __rte_alloc_func(), but uses it in the next patch in t= he series. > Suggest either doing both here, or move the definition of __rte_alloc_fun= c() to the next patch. >=20 >=20 > > +/** > > + * Tells the compiler this is a function like malloc and that the > > pointer > > + * returned cannot alias any other pointer (ie new memory). =20 >=20 > There's a good example of its use here: > https://developers.redhat.com/blog/2021/04/30/detecting-memory-management= -bugs-with-gcc-11-part-1-understanding-dynamic-allocation#detecting_mismatc= hed_deallocations >=20 > It not only refers to memory, but also handle pointers. > You might want to replace "ie new memory" by "ie new object" or similar. >=20 >=20 > Please add the optional arguments to pass to __rte_alloc_func to the macr= o description, e.g.: > @param [free_func] > The name of the deallocation function to free the allocated object > @param [free_func_ptr_index] > The deallocation function's argument index of the object pointer. >=20 > PS: The brackets indicate that the parameter is optional. I didn't know, = so it is what I found on the internet. In later versions of the patch decided that naming and parameters should follow the precedent used in glibc. See new version sent today.