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 CFD4443AA0; Tue, 6 Feb 2024 17:17:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D3B8402B5; Tue, 6 Feb 2024 17:17:36 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id D734A4026B for ; Tue, 6 Feb 2024 17:17:34 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 656C713745 for ; Tue, 6 Feb 2024 17:17:34 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 44452136EA; Tue, 6 Feb 2024 17:17:34 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.4 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id B1ACD137B9; Tue, 6 Feb 2024 17:17:32 +0100 (CET) Message-ID: Date: Tue, 6 Feb 2024 17:17:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "dev@dpdk.org" Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Subject: rte_malloc() and alignment Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 The rte_malloc() API documentation has the following to say about the align parameter: "If 0, the return is a pointer that is suitably aligned for any kind of variable (in the same manner as malloc()). Otherwise, the return is a pointer that is a multiple of align. In this case, it must be a power of two. (Minimum alignment is the cacheline size, i.e. 64-bytes)" After reading this, one might be left with the impression that the parenthesis refers to only the "otherwise" (non-zero-align) case, since surely, cache line alignment should be sufficient for any kind of variable and it semantics would be "in the same manner as malloc()". However, in the actual RTE malloc implementation, any align parameter value less than RTE_CACHE_LINE_SIZE results in an alignment of RTE_CACHE_LINE_SIZE, unless I'm missing something. Is there any conceivable scenario where passing a non-zero align parameter is useful? Would it be an improvement to rephrase the documentation to: "The alignment of the allocated memory meets all of the following criteria: 1) able to hold any built-in type. 2) be at least as large as the align parameter. 3) be at least as large as RTE_CACHE_LINE_SIZE. The align parameter must be a power-of-2 or 0. " ...so it actually describes what is implemented? And also adds the theoretical (?) case of a built-in type requiring > RTE_CACHE_LINE_SIZE amount of alignment.