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 DF335425A6; Fri, 15 Sep 2023 17:43:58 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6125B402B8; Fri, 15 Sep 2023 17:43:58 +0200 (CEST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by mails.dpdk.org (Postfix) with ESMTP id CEA35402AF for ; Fri, 15 Sep 2023 17:43:56 +0200 (CEST) Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-1c1e3a4a06fso19143035ad.3 for ; Fri, 15 Sep 2023 08:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1694792636; x=1695397436; 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=h6q0+J46VVzl1OH4cj6dXFz6FMrX6BZez8W0Lj7kV8o=; b=cXFVtchNJ/adIfsXe45H/IEaTSRX9/q2UNdkUphd3lOXyBtqfvKLKt3Tnl8kgLEs7w MG3pgiT19/MjFX1KD7GTNBNCzvVr2iRg8qDNfAxezvOeejs0eGuIIZPlP4RUV+TbTaYD m2+OVQNBLvVHdmleJs1EegdxmrHUsvZ0yrMY0WerbW8hAn8NC/FcEAQODbUHNW3JEfVl vxgjBJxL/JdMEUZ27mxC+/5o3w7Y+6Ees98L6ORVaEyb9OApfCzOiOJYY5DwrheUs52e N3u1uDxOkGKJBpT14jy66iEVkhiMZvWXB+KbawKDUWUm1XVHyPPOPId1w5YacS8Spitb p+0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694792636; x=1695397436; 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=h6q0+J46VVzl1OH4cj6dXFz6FMrX6BZez8W0Lj7kV8o=; b=Z7tOusVMOcmI23Y0GmP0Q3JFmnKBRAYrHHoHk76SvGhGx+8vkEgy1tPn81qLya8gPf t9BjW6DSXb9+Be/SlKA8yzxiD/cNgL318X4X34nelUPnV/iBk272Bl8wZ7kd+md/FC7L 6mgljnYCGctb3ZwYRELAZbA+K+AKiIvD31n/f1szdgv4Og/GMSgRlFPB4AyjZ/qgY6g7 /cdjUQIrnvw2J6oJF9uI14PW3fNiGhK2tKu+D7WJEt7a48N4CAZO1iaN8Pf4oneurq5W /jV/DZhdRF0x+AfTOo1Veks5Y6zVmDz759toLumNQ5ge6eKOEah0ffy47+6N36Ol7149 A2hg== X-Gm-Message-State: AOJu0Yy46/RaRzFaKiKvmv7mBiZmRT8a18rd3SL3mJTllceeA+x9YKXr rs+W4oFz7SN4otmp7D1CyVKsFQ== X-Google-Smtp-Source: AGHT+IGf77MQh2QBxUNNeox5un1miDc55/9v3sg5Zp9R0T1svBEZrMaF2EBFmFcCKyeddyHB0T/9ug== X-Received: by 2002:a17:902:7e8a:b0:1c3:a2ea:64d3 with SMTP id z10-20020a1709027e8a00b001c3a2ea64d3mr1425073pla.41.1694792635774; Fri, 15 Sep 2023 08:43:55 -0700 (PDT) Received: from hermes.local (204-195-112-131.wavecable.com. [204.195.112.131]) by smtp.gmail.com with ESMTPSA id p10-20020a170902eaca00b001b89f6550d1sm1491366pld.16.2023.09.15.08.43.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 08:43:55 -0700 (PDT) Date: Fri, 15 Sep 2023 08:43:53 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: dev@dpdk.org, Anatoly Burakov Subject: Re: [PATCH] eal: allow swapping of malloc heaps Message-ID: <20230915084353.51023491@hermes.local> In-Reply-To: <20230915122703.475834-1-bruce.richardson@intel.com> References: <20230915122703.475834-1-bruce.richardson@intel.com> 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, 15 Sep 2023 13:27:03 +0100 Bruce Richardson wrote: > The external memory functions in DPDK allow the addition of externally > access memory to malloc heaps, but with one major restriction - the > memory must be allocated to an application-created heap, not one of the > standard DPDK heaps for a NUMA node. > > This restriction makes it difficult - if not impossible - to use > externally allocated memory for DPDK by default. However, even if the > restriction is relaxed, so we can add external memory to e.g. the socket > 0 heap, there would be no way to guarantee that the external memory > would be used in preference to the standard DPDK hugepage memory for a > given allocation. > > To give appropriately defined behaviour, a better solution is to allow > the application to explicitly swap a pair of heaps. With this one new > API in place, it allows the user to configure a new malloc heap, add > external memory to it, and then replace a standard socket heap with the > newly created one - thereby guaranteeing future allocations from the > external memory. > > Signed-off-by: Bruce Richardson > --- Should document any restrictions about when this can be done. Doesn't look thread safe. Would expect that application would do this just after EAL init before doing any work. What happens to memory allocated from old heap.