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 886E041B7E; Mon, 30 Jan 2023 11:00:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1912640EDE; Mon, 30 Jan 2023 11:00:43 +0100 (CET) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by mails.dpdk.org (Postfix) with ESMTP id 23F7540C35 for ; Mon, 30 Jan 2023 11:00:41 +0100 (CET) Received: by mail-ej1-f45.google.com with SMTP id qw12so14188397ejc.2 for ; Mon, 30 Jan 2023 02:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=Uh6j+XuLR1m3qf9XB7JlWCdVYyst6Hr9q3YTr8E89zE=; b=mh5rKxvpIXeR5QoCXxC5zBbtFcrJExmpNjQ1apiHQWRWY3IHopjyuzWVOHAWLzdIpR yeNZNdy6eWGKdtPRHNHRrAfMYmZwOmiekvzdGws4bNtZRmLBlWnnbr/ZQRiFTKMirY2D 3oVQ8/eHEwaV8lRHTDGpnUyaWYsvlt+vasFe7G0Frd24rriUOStXefl+xqnqrCuyJBhz Oih8r5O+knxNh+WEMZmWHAE1zOR0UyyS55FiNjAWSQVR/3qvulXStIai8O+IYijI6kM2 6BVMIq7nkprOwCmlw0GoUcBYFiFS351oDBSUdoB7r2YoMlR4jbXsRcv6GqIrBbzoiEB+ WkCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Uh6j+XuLR1m3qf9XB7JlWCdVYyst6Hr9q3YTr8E89zE=; b=Owkwaw3aeSEKi1a9YlDedvOQX+dWkKVoz7rOZH2CWgBF8Y0l1eQmUCywz8p4b4Skfl CRfq1kOo00V0WyfFhqaom10m/xAXDz5KnCZnCwp0ZbSnLilebgJW130UlS9jcqjupygr IDjY5j0ssPIRrL3UidY/7a1nRXM7gR2Q9+2n2ZYMSSj8HistQRCHCWU2Lv3FmSKCdubS odwdv1gMEmC59mN2qo55TSJYfCI5HhUZHZvD/r3zfO+jbLnjgImOZniWJ0VEsDVYUASc 6KuBPC//4GVVdMB731ejxvv+p746dbhFKntTBr2g3ublPQArKxMLcqq3Mv4pBYWA6n+2 L3dg== X-Gm-Message-State: AO0yUKVYWsZFYhwoy/iJNwQ1hRzUJke+d7gAw1uf2466oarFxVMN7oLQ PABNPTUTGVFB7VQjnDlev40= X-Google-Smtp-Source: AK7set8o7HiZ4SoIjPGhup+VT5z1SdYiMRvTeFKHlyUm9xZVIed4KkG2qwpqlSOW2cviL4rtLo3xsg== X-Received: by 2002:a17:906:fac6:b0:888:a29:b645 with SMTP id lu6-20020a170906fac600b008880a29b645mr3969063ejb.64.1675072840703; Mon, 30 Jan 2023 02:00:40 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id bj14-20020a170906b04e00b00878a8937009sm5854496ejb.199.2023.01.30.02.00.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Jan 2023 02:00:40 -0800 (PST) Date: Mon, 30 Jan 2023 13:00:38 +0300 From: Dmitry Kozlyuk To: Ophir Munk Cc: , Ophir Munk , Matan Azrad , "Thomas Monjalon" , Bruce Richardson , Lior Margalit Subject: Re: [RFC] config: customize max memzones configuration Message-ID: <20230130130038.1d75cc01@sovereign> In-Reply-To: <20230130092302.376145-1-ophirmu@nvidia.com> References: <20230130092302.376145-1-ophirmu@nvidia.com> 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 2023-01-30 11:23 (UTC+0200), Ophir Munk: > In current DPDK the RTE_MAX_MEMZONE definition is unconditionally hard > coded as 2560. For applications requiring different values of this > parameter =E2=80=93 it is more convenient to set its value as part of the= meson > command line or to set the max value via an rte API - rather than > changing the dpdk source code per application. >=20 > An example would be of an application that uses the DPDK mempool library > which is based on DPDK memzone library. The application may need to > create a number of steering tables, each of which will require its own > mempool allocation. This RFC is not about how to optimize the > application usage of mempool nor about how to improve the mempool > implementation based on memzone. It is about how to make the max > memzone definition - build-time or run-time customized. >=20 > I would like to suggest three options. >=20 > Option 1 > =3D=3D=3D=3D=3D=3D=3D=3D > Add a Meson option in meson options.txt and remove the > RTE_MAX_MEMZONE definition from config/rte_config.h >=20 [...] >=20 > Option 2 > =3D=3D=3D=3D=3D=3D=3D=3D > Use Meson setup -Dc_args=3D"-DRTE_MAX_MEMZONE=3DXXX" and > make RTE_MAX_MEMZONE conditional in config/rte_config.h >=20 > For example, see the code of this commit. >=20 > Option 3 > =3D=3D=3D=3D=3D=3D=3D=3D > Add a function which must be called before rte_eal_init(): > void rte_memzone_set_max(int max) {memzone_max =3D max;} > If not called, the default memzone (RTE_MAX_MEMZONE) is used. >=20 > With this option there is no need to recompile DPDK and it allows > using an in-box packaged DPDK. [...] Ideally, there should be no limitation at all. I vote for some compile-time solution for now with a plan to remove the restriction inside EAL later. Option 2 does not expose a user-facing option that would be obsoleted anywa= y, so it seems preferable to me, but Option 1 is also OK and consistent. `RTE_MAX_MEMZONE` is needed currently, because `struct rte_memzone` are sto= red in `rte_fbarray` (mapped file-backed array) with a fixed capacity. Unlike e.g. `rte_eth_devices`, this is not used for efficient access by ind= ex and is not even exposed to PMDs, so the storage can be changed painlessly. In DPDK, only net/qede uses this constant and also for slow-path bookkeepin= g.