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 0C12843A0B; Wed, 7 Feb 2024 05:46:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 99514402EE; Wed, 7 Feb 2024 05:46:26 +0100 (CET) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by mails.dpdk.org (Postfix) with ESMTP id A3187402EC for ; Wed, 7 Feb 2024 05:46:25 +0100 (CET) Received: by mail-oi1-f176.google.com with SMTP id 5614622812f47-3bfdb5a5a63so110947b6e.2 for ; Tue, 06 Feb 2024 20:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1707281185; x=1707885985; 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=yEqIJHcxS6WbWRgW/dHNle/h1Zmw2nHEHhQc2LP62Fc=; b=KOEJbVCqlTyBJzD5aGFJjTR4S9zRtdqWsJqTWm9oqn72HCtgtfxFR5yTB3d+pc6XLc mtaSAEGBNOc5Zn13iQshmZN2rhcpZ85hpRQRUNMtIdO597VSeWXpjV4bYwmz3O9nLECp c6vDyuwZ0Jm8bDe3nrRcUAMCXP+A1mRAsdRzUwMAVI1CT6dNx019zp5WGsLjgn8V0L39 K0DeilJoFjU84CyZu031rmEs1LkXvu6oDpAl7D3GonRzHxGkXyeNzgq7C71LCgvDJVTT NS4/ARgN1nsHODvyOn7FnVZ+xbuYwcPCgeZQMjPJnoeMfzk/ASh3kfsd8fwZasHRsFrV aeTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707281185; x=1707885985; 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=yEqIJHcxS6WbWRgW/dHNle/h1Zmw2nHEHhQc2LP62Fc=; b=WJ88jte6Bprzb3FvuPqJ4JFntxJCrpYwHOeEOp1huzkaiI+OleYuHov/cL6bzLSYEN 94Pcc6A5kbV3YnvcWCEdF9RlEWLE6so6mUWi9+l8FqgqfOpY82IA3TfLdtSqwktbUcP5 Y23Fi5gyZHeFSSzSPAKyX2eOcv1cHfE8MTGlrk2wz9/exgxDuJ6nx6w2nkTSxd59V9ir wsSpEDL+Wvpz/O79zKUWS5uyAfOfquPdUweiqwcqBkH/WbHfk4IJ5oHQv07yIE/HmJDF 5tKq3LS5UyGnfn7VHqSLScpq5r2F9P7ELuXWMn7UlAwJbEDEDLJOGR+LNSNOrfrVw8De 4oSw== X-Gm-Message-State: AOJu0Yycu4LTDWTkcExG0wgmMrd18aDXd0NuwSCVjSJVWrgBT8Qj6bMF yrjYV0IFKFXDjrpGqmrAhoNKwuNbvVpQZmlt77ETQMd2iVlQwdvo/Z9nNQD6hcU= X-Google-Smtp-Source: AGHT+IGGJCMAG30wTaXpW5ITRKTEoK80wrgot6QMb4nwNvBQRzsYvvFnTrf0GImWkAf2/sSpShINSA== X-Received: by 2002:a05:6808:2f18:b0:3bf:e5ba:df45 with SMTP id gu24-20020a0568082f1800b003bfe5badf45mr4880548oib.49.1707281184767; Tue, 06 Feb 2024 20:46:24 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCW6naliZjHofXkrQz8xYADgY9fWK0cGW0SEZdTdtYQ7r4gFb0dV3Ik5fMpymmCnFMMKCxnbxa6KvyuRIZ4s8R59DbCO7W1KD/2M+eILkg== Received: from hermes.local (204-195-123-141.wavecable.com. [204.195.123.141]) by smtp.gmail.com with ESMTPSA id n7-20020aa79847000000b006e048853e1esm390511pfq.215.2024.02.06.20.46.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Feb 2024 20:46:24 -0800 (PST) Date: Tue, 6 Feb 2024 20:46:22 -0800 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: "dev@dpdk.org" , Mattias =?UTF-8?B?UsO2bm5ibG9t?= Subject: Re: rte_malloc() and alignment Message-ID: <20240206204622.6fc99cac@hermes.local> In-Reply-To: References: 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, 6 Feb 2024 17:17:31 +0100 Mattias R=C3=B6nnblom wrote: > The rte_malloc() API documentation has the following to say about the=20 > align parameter: >=20 > "If 0, the return is a pointer that is suitably aligned for any kind of=20 > variable (in the same manner as malloc()). Otherwise, the return is a=20 > pointer that is a multiple of align. In this case, it must be a power of= =20 > two. (Minimum alignment is the cacheline size, i.e. 64-bytes)" >=20 > After reading this, one might be left with the impression that the=20 > parenthesis refers to only the "otherwise" (non-zero-align) case, since=20 > surely, cache line alignment should be sufficient for any kind of=20 > variable and it semantics would be "in the same manner as malloc()". >=20 > However, in the actual RTE malloc implementation, any align parameter=20 > value less than RTE_CACHE_LINE_SIZE results in an alignment of=20 > RTE_CACHE_LINE_SIZE, unless I'm missing something. >=20 > Is there any conceivable scenario where passing a non-zero align=20 > parameter is useful? >=20 > Would it be an improvement to rephrase the documentation to: >=20 > "The alignment of the allocated memory meets all of the following criteri= a: > 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. >=20 > The align parameter must be a power-of-2 or 0. > " >=20 > ...so it actually describes what is implemented? And also adds the=20 > theoretical (?) case of a built-in type requiring > RTE_CACHE_LINE_SIZE=20 > amount of alignment. My reading is that align of 0 means that rte_malloc() should act same as malloc(), and give alignment for largest type.=20 Walking through the code, the real work is in and at this point align of 0 has been convert to 1. in malloc_heap_alloc_on_heap_id() /* * Iterates through the freelist for a heap to find a free element with the * biggest size and requested alignment. Will also set size to whatever ele= ment * size that was found. * Returns null on failure, or pointer to element on success. */ static struct malloc_elem * find_biggest_element(struct malloc_heap *heap, size_t *size, unsigned int flags, size_t align, bool contig) Then the elements are examined with: size_t malloc_elem_find_max_iova_contig(struct malloc_elem *elem, size_t align) But I don't see anywhere that 0 converts to being aligned on sizeof(double) which is the largest type. Not sure who has expertise here? The allocator is a bit of problem child. It is complex, slow and critical.