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 CE690432B4; Mon, 6 Nov 2023 05:35:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 596C4402B5; Mon, 6 Nov 2023 05:35:34 +0100 (CET) Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by mails.dpdk.org (Postfix) with ESMTP id 673894027F for ; Mon, 6 Nov 2023 05:35:33 +0100 (CET) Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-9d2c54482fbso605302166b.2 for ; Sun, 05 Nov 2023 20:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699245333; x=1699850133; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=k6Z8KPMcgF1zKDW+kbzvsUA6dE0aJ38BeK0htfgMuhM=; b=PdaESGXeUOXvrvJbRQbEuWlWS9ZCvz/00LaBKNzZxdTNe+dqXct3M5Rlfk4G4o0seg xVGGh9SGi0mEuMxFhw/hLEfZAoQu21oOh5L92UvdlFy5Kax7UFF2sQvGdUE/cwbNURRk ME8ow1BJzfs17FiXqTPFsBjzhEo47DX0J6FE0EH+05uPXIqg0/NFdmSKqZJL+BVZMwvC oHUbT0JLeA6k+PlZH1Ws6W+erHL8QQ8bALxr+ECyMMFK0XmLXdutxCDNdIhVAXTtUxsE C+RxWbFrcnc+D6D+Gwkhwdlx3bbvjzBKzReYsjjMYUpnI4nYYKAjBME2wgb6uLfD5FUj 22Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699245333; x=1699850133; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k6Z8KPMcgF1zKDW+kbzvsUA6dE0aJ38BeK0htfgMuhM=; b=Kz+KS+jvcCX4Ux0YHaDFA47wcGyXvXKEWtOAdVXBp2IGv3gNm47RjUn2wxfcUWCyTf H7r4m1S7jAi+oxJVvDmP6NuUrfdwjOhIEJfSFkAoXG8bPFz1A9dFne8wYNNs0PbxfUB9 Bj8Rqlpy3A4t1WLW6HE0Q9Kcc2k5MocByErjrne72onObU6mcwLRBLdnU06UYnMIpI5e j1+I956Hmo9nwTplK3iOBIWxf3ey0/rjrh2yKU9/mbf7pr2Fy/ZzBRArlwtkb5TX2aiK 3upA/BvEMmoWwEw4/NP7h3CYo905kT6Sbg2w70j/o10q7OQCFtmas+AWWHLNsKF0Z0Uz i3gw== X-Gm-Message-State: AOJu0YyxpAf7PlaQmDX/HG+DrzTqLtOPTndczT27aSGb7iwybwDuuPs+ PnH/7oRmRJjUnZtu8eQwxjBlw2VXGW8tSufBhZ4= X-Google-Smtp-Source: AGHT+IHjZIgKWPjgesSMw09OGLtQtLPts/9KmH19HSpsN3BPML7OIVh5Ti6mSrMXvaxNv3LwAnl09PcfrexxKLHM2Cs= X-Received: by 2002:a17:907:c20c:b0:9da:eefb:854c with SMTP id ti12-20020a170907c20c00b009daeefb854cmr10792436ejc.25.1699245332653; Sun, 05 Nov 2023 20:35:32 -0800 (PST) MIME-Version: 1.0 References: <3585796.R56niFO833@thomas> <7fa897991d4c5f1d0b91b65ce58276c5fa434bbd.camel@scylladb.com> In-Reply-To: <7fa897991d4c5f1d0b91b65ce58276c5fa434bbd.camel@scylladb.com> From: kefu chai Date: Mon, 6 Nov 2023 12:35:21 +0800 Message-ID: Subject: Re: configuration of memseg lists number To: Avi Kivity Cc: Thomas Monjalon , anatoly.burakov@intel.com, david.marchand@redhat.com, bruce.richardson@intel.com, dev@dpdk.org Content-Type: multipart/alternative; boundary="000000000000706bfc0609746299" 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 --000000000000706bfc0609746299 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 5, 2023 at 5:56=E2=80=AFPM Avi Kivity wrote: > Thanks, it makes sense. I'll get around to it "eventually". > > On Thu, 2023-11-02 at 11:04 +0100, Thomas Monjalon wrote: > > Hello, > > While looking at Seastar, I see it uses this patch on top of DPDK: > > build: add meson options of max_memseg_lists > > RTE_MAX_MEMSEG_LISTS =3D 128 is not enough for high-memory machin= es, > in our case, we need to increase it to 8192. > so add an option so user can override it. > > https://github.com/scylladb/dpdk/commit/cafaa3cf457584de > > I think we could allow to configure this at runtime, > as we did already for RTE_MAX_MEMZONE: > we've added rte_memzone_max_set() / rte_memzone_max_get(). > > Opinions, comments, volunteers? > > Hi Thomas, Thank you for looking into it. I sent this patch[0] to DPDK 2 years ago. but i failed to find a solid proof to prove that we need such a massive number, and failed to follow-up on the suggestion[1] on calculating his number based on the lcores / numa node as I was trying to port the newer dpdk to seastar at that moment, so dropped the ball on my end, sorry for that. just revisited the places where we use RTE_MAX_MEMSEG_LISTS. it seems it would be a bigger effort to make it a run-time configurable option instead of a compile-time one. -- [0] https://inbox.dpdk.org/dev/20211013205417.84119-3-tchaikov@gmail.com/ [1] https://inbox.dpdk.org/dev/2642296.XfZ1dg20Xv@thomas/ --=20 Regards Kefu Chai --000000000000706bfc0609746299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 5, 2023 at 5:56=E2=80=AFP= M Avi Kivity <avi@scylladb.com&g= t; wrote:
Thanks, it makes sense. I'll = get around to it "eventually".

On Thu, 2= 023-11-02 at 11:04 +0100, Thomas Monjalon wrote:
Hello,

While looking= at Seastar, I see it uses this patch on top of DPDK:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0build: add meson op= tions of max_memseg_lists

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0RTE_MAX_MEMSEG_LISTS =3D 128 is not enough fo= r high-memory machines,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0in our case, we need to increase it to 8192.
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0so add an option so user can o= verride it.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0https://github.com/scylladb/dpdk/commit/cafaa3cf= 457584de

I think we could allow to configu= re this at runtime,
as we did already for RTE_MAX_MEMZONE:
we've added rte_memzone_max_set() / rte_memzone_max_get().<= br>

Opinions, comments, volunteers?

Hi Thomas,=C2=A0
=

Thank you for looking into it. I sent this patch[0] to = DPDK 2 years ago. but i failed to find a solid proof to prove that we need = such a massive number, and failed to follow-up on the suggestion[1] on calc= ulating his number based on the lcores / numa node as I was trying to port = the newer dpdk to seastar at that moment, so dropped the ball on my end, so= rry for that. just revisited the places where we use RTE_MAX_MEMSEG_LISTS. = it seems it would be a bigger effort to make it a run-time configurable opt= ion instead of a compile-time one.

--

--
Regards
Kefu Chai
--000000000000706bfc0609746299--