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 8F545A0C4E; Mon, 8 Nov 2021 18:45:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0BAB040151; Mon, 8 Nov 2021 18:45:43 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id 1808E40040 for ; Mon, 8 Nov 2021 18:45:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636393540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RVAZDywv5uY4StpMYQjcAYA25M5KmxhcDbK/W2Q4jn8=; b=O1MKZkz/vsykwv52RaoqxZ09lYYNXO5TzOJmC4ePBVU08OvuN61vNXwOH/k+7txdDOnEG/ 4uyheYcgXVll2i1TkCuEVUilo4Xl6/FAWpUGwljAXMArRouHA4VdiSj0/kQ/DfBZwIX1IW PueWznoJy48UUHkaaSZglzYQ7XXcths= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-20CJYXEkOsGNJII4FgqCyg-1; Mon, 08 Nov 2021 12:45:39 -0500 X-MC-Unique: 20CJYXEkOsGNJII4FgqCyg-1 Received: by mail-lf1-f72.google.com with SMTP id h40-20020a0565123ca800b00402514d959fso5354423lfv.7 for ; Mon, 08 Nov 2021 09:45:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RVAZDywv5uY4StpMYQjcAYA25M5KmxhcDbK/W2Q4jn8=; b=gFyj1fM03Aq6InMog6nRy/CnlqyrquLfxH2gJFPcY3hqzLJ/J3s09p/qjXB68Qpgtj 9+jhtrNrSKQ8gOWOxpYOpZeuPVD7vHPgRu3MW+BAQXyK1i7hS/YEpGSSXzpyOGgClzvl bZgvSTVG1tsOXLDE7Dr4c+YOBBrk+AjF8hqHmDv5PmO0SzcnKpA9TpMb9ZqIWS5jdvKk U+Ymjo2Efbrz19SOcFSdKWYKv6m3FQ1zHAnWnPrJuFpbgbE7T/6ZgSY527qeHqYjfVRL SsX68pyOUMg6KrXOZU+woxkt9mhQ2qdaylfYw/Lu44RPSRC9WQr2LNwkJDdN25pkw4jI uNJw== X-Gm-Message-State: AOAM530jp+luuDoCpKt+eU9XjJA4KvSlvS1ffbtYEF0/iwE7u1ASQtvF vyli/qTjkxjaZwIzU4ouvCiQbYweoZEFuyw8Nv2SmevzNqRSX7LeEcMBBigAJx6dYiigs4/YXx6 LHd43Lp4gi4ZksF/nxtk= X-Received: by 2002:a2e:9085:: with SMTP id l5mr759903ljg.81.1636393537583; Mon, 08 Nov 2021 09:45:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJz24DU1xJ1KOZnivAnjZW9puWw6YQQpI9hk9CpEIKxlxGc6zJFsAQ5x6RDFrPzag93CEytMO7t8yN10oEDUQ1I= X-Received: by 2002:a2e:9085:: with SMTP id l5mr759878ljg.81.1636393537428; Mon, 08 Nov 2021 09:45:37 -0800 (PST) MIME-Version: 1.0 References: <20210921081632.858873-1-dkozlyuk@nvidia.com> <20211011085644.2716490-1-dkozlyuk@nvidia.com> <20211011085644.2716490-3-dkozlyuk@nvidia.com> In-Reply-To: From: David Marchand Date: Mon, 8 Nov 2021 18:45:26 +0100 Message-ID: To: Dmitry Kozlyuk Cc: dev , Slava Ovsiienko , Anatoly Burakov , NBU-Contact-Thomas Monjalon Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v6 2/3] eal: add memory pre-allocation from existing files 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 Sender: "dev" On Mon, Nov 8, 2021 at 3:27 PM Dmitry Kozlyuk wrote: > > Hi David, > > > -----Original Message----- > > From: David Marchand > [...] > > > > - finegrained control of hugepage files, but it has the drawback of > > > > imposing primary/secondary run with the same options. > > > > The second part seems complex to configure. I see conflicts with > > > > existing options, so it seems a good way to get caught up in the > > > > carpet (sorry if it translates badly from French :p). > > > > > > I don't see why synchronizing memory options is a big issue. > > > > We have too many options for the memory subsystem. > > > > I mentionned --socket-mem, --huge-dir, --file-prefix. > > But there is also --huge-unlink, --no-shconf, --in-memory, --legacy-mem, - > > -single-file-segments, --match-allocations and --socket-limit. > > Some of those do part of the job, others are incompatible with this new > > option and probably some are orthogonal. > > > > Sure we can add a new one that prepare your toasts, coffee and wake up the > > kids (that's progress!). > > > > Maybe you can provide an example on how this is used? > > Sorry for the late reply. No problem. > > After more consideration offline with Thomas > we concluded that the --mem-file option is indeed too intrusive. > I'm going to propose a new solution for the slow restart issue for 22.02, > probably with a knob like you proposed, > only not just changing when the memory is zeroed, > but most importantly allowing EAL to reuse hugepages. > So that in the end the usage would be as follows, > and if it's a restart, memory clearing would be bypassed: > > ./dpdk-app --huge-reuse -- ... > > Refactoring and benchmark patches may still be useful, > so review efforts were hopefully not in vain. > Thank you for asking the right questions! > > FWIW, I agree that memory options should be cleaned up independently. Looking forward to 22.02 :-). Thanks Dmitry. -- David Marchand