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 DF42543A96; Wed, 7 Feb 2024 09:05:30 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7228F40295; Wed, 7 Feb 2024 09:05:30 +0100 (CET) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by mails.dpdk.org (Postfix) with ESMTP id DB35340279 for ; Wed, 7 Feb 2024 09:05:29 +0100 (CET) Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-51167496943so339785e87.2 for ; Wed, 07 Feb 2024 00:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707293129; x=1707897929; 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=LnAIIdYD0NHIJHxMGCrMrAy61dm9+FCyAFcLN5B0jJQ=; b=Yz9j8hrydIWJTulDntSHsiqKbgIqgYBbJ8S13XNyR03VaYeX/HJtj69bc4u/vrka+f O9ripuCQEksaQnCtYMnn6EOYonCfn2obVa06CfSHIdz06oSJs5JWGTfsa+DkgeEADiu1 VL96VdfP94VNXJzXlXVImkFuyprWKzS0mFT4rAFqCKT336WdLwJ+6hDg3EkmSCdNVlgJ PuGkK06ZDV7yPrRxKWt6Q2Y3615nL+T4UvAZ8aKsuetmaipHf7bEopyc7ZI61+KdZ8hs POX3ppg2iL053Zdnz5Tw1i2l1zUvdrD2YMOnb5imSxwu5vWGl8XHzTomfqEVH8xz57FC /aaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707293129; x=1707897929; 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=LnAIIdYD0NHIJHxMGCrMrAy61dm9+FCyAFcLN5B0jJQ=; b=WlJs3HMpnerhMavyy0C059uFfGSMp/NM65hDIo6fwckgjkGHo9Sqt2hLQ2VDrDHHCa T/eMpxmjRZ0akdeSB7OdHtv1QMuTObWbdIIJykH7uCUNzyk18XV40gSHJ1tPCkPhx/EA HoSFCJlFVpLJjJWYcKQt1Rsl0CAAwC/Rc3+Ki8cK4hRbUlk8nfG0MYONODPEK4Svzueq 1IiSSW/nQn2dG+WmSS06ljsQl9qE2o31hbakVq1nr6awd4L9jVbcoXlCOMLwyZUgdNrd 935bo1G4qMRItOnYmY6FNEYdX66Kc8MjiY3Kfe/59yycjthqabMcgUABqo1vG2SQpJs8 3r+g== X-Gm-Message-State: AOJu0Yy/c6dhK+Wmjtn87kLjOtAfIrzELDXZWigcOTqvpIK/hmbtU6Mr Z7hEAj5LruCv0861mv/X6p8Q8jMGo6QzB/EcbA2lweTLuxr3teWm X-Google-Smtp-Source: AGHT+IEnKP3+DwnnOugllXK+xJUdzjT/wwC2+VxDAI5AbEUTXeUx6tWGsOrdc+jXbp3/cce4yZ9QCw== X-Received: by 2002:a05:6512:31c7:b0:511:54e8:b82e with SMTP id j7-20020a05651231c700b0051154e8b82emr3718838lfe.47.1707293128719; Wed, 07 Feb 2024 00:05:28 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXb9khyAOXVf+LC4hTA+kPEajJ/jGiFaFGCvIlB6Up/Gk4xLYkARXGE/RCFVx1uNPkoMHby2lZEl+d5Fg0F6VAJLygMtKxx7uKujLvPuh6fuC8MsV0N0Hew+LaQQAcauoeIA2Og1c9XGuc6ERNg3MUd3JN17xLg Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id m16-20020a056512115000b005114d401157sm96960lfg.2.2024.02.07.00.05.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 00:05:28 -0800 (PST) Date: Wed, 7 Feb 2024 11:05:27 +0300 From: Dmitry Kozlyuk To: Stephen Hemminger Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , "dev@dpdk.org" , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Anatoly Burakov Subject: Re: rte_malloc() and alignment Message-ID: <20240207110527.03bb7c5f@sovereign> In-Reply-To: <20240206204622.6fc99cac@hermes.local> References: <20240206204622.6fc99cac@hermes.local> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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 2024-02-06 20:46 (UTC-0800), Stephen Hemminger: > On Tue, 6 Feb 2024 17:17:31 +0100 > Mattias R=C3=B6nnblom wrote: >=20 > > 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 o= f=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 crite= ria: > > 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. =20 >=20 > My reading is that align of 0 means that rte_malloc() should act > same as malloc(), and give alignment for largest type.=20 >=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() >=20 > /* > * Iterates through the freelist for a heap to find a free element with t= he > * biggest size and requested alignment. Will also set size to whatever e= lement > * 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) >=20 >=20 > Then the elements are examined with: >=20 > size_t > malloc_elem_find_max_iova_contig(struct malloc_elem *elem, size_t align) >=20 > But I don't see anywhere that 0 converts to being aligned on sizeof(doubl= e) > which is the largest type. One may also read "in the same manner as malloc()" as referring to "suitably aligned", which means that the alignment is "as suitable as malloc()'s" and it may also be larger. Then comes the assumption that no built-in type = has alignment larger than a cache line (can vectored types be the case?). > Not sure who has expertise here? Added Anatoly. > The allocator is a bit of problem child. > It is complex, slow and critical.