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 9F37F48871; Tue, 30 Sep 2025 15:06:34 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 70C7D402E1; Tue, 30 Sep 2025 15:06:34 +0200 (CEST) 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 98BEC4025F for ; Tue, 30 Sep 2025 15:06:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1759237593; 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=EeH7aAPugHuCbISI7zrFbw6r5Htitdcdl83OHwz3etk=; b=JOBSkKOSfJhMejgbY+qHFcdWvn01vDLHjIvTaf6PyLFCAjb3L0XaCMtMXO2NmQGjFRxLwj bG3Eyg1gyqUeq0dC1L+qynstE8SKvLWnaCMU/db4GtHiCbqGdSCX42BL6ekHak1hiEH+IK X7YfKe7eO7fVSP/AUnsFznbB5xno+7E= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-80-MlJ5euwOOqm1keBntQyrpQ-1; Tue, 30 Sep 2025 09:06:30 -0400 X-MC-Unique: MlJ5euwOOqm1keBntQyrpQ-1 X-Mimecast-MFC-AGG-ID: MlJ5euwOOqm1keBntQyrpQ_1759237589 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-333f8f1d00aso27700731fa.1 for ; Tue, 30 Sep 2025 06:06:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759237589; x=1759842389; 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=EeH7aAPugHuCbISI7zrFbw6r5Htitdcdl83OHwz3etk=; b=PhVUvMlZAstYuwO+1MUo8D+woXIHx32xTxRSTVjK7pW3LMCiNHtZLhe7BAYTyEVO8G o6nyMwIoRoPkMUbmTmKwveE4cJjF3Dwjl8IaUXMveH0fdaBRnze+jBzM7uurmxcQGSgN AP3Ogc5RTb4ajfnnRpI3aKFhb7AkTRkHDCvrc8w/uFKfa4T8SeF5EHbuAjzGFJOVkEWW tFK958zdnubWPOJZRyoSkgWJW1KRpoPA5nQkqlBCvughtn34y/MWedcF5jH4UTN0qdq1 8FB7bIPesXyJMUKDkDrYtOiGN/UGdbfyxy6iPYL/B7KA9a+Kq40Fx0Bg6Xoht3pZosXJ rhuQ== X-Gm-Message-State: AOJu0YyIt8JgrPKpmRor4oUdWVksRj1FFsItw6VDH27kXFykkn3ZNpDj ESPcDeYSpdDC0+yf+GDjqF+lz3a7d66lMTSJz3iGkN7JeK2nvoagotl3t8zez7Li4H1LCrqf9Dg YTZaJD17b67ci02GyAKYYMS6C8Yp3rjMjY4doAyYECmfVn8Ibv8UUk0uuIMRuObai1A8IEuobRG 3Jg3BTxeSsixL1nlC+V+Q= X-Gm-Gg: ASbGncs2QsIMVu8rkJ4QAIIShEmTPYVeJS4TTmbkb9e9tMqeREHUFHDu9atgpREGa38 K4TazDG/5nVZcXbumUkZrY1GA1tghepP74YQh0+UdfVaMAtSwAPkR5FEmKDEiQSNDzbVJ2ghvg/ Sux5yZ/JOk08cAB2f+ncrCsB3XFvDV X-Received: by 2002:a05:651c:c8a:b0:36c:259a:c921 with SMTP id 38308e7fff4ca-36f7e980d5amr58438531fa.13.1759237588964; Tue, 30 Sep 2025 06:06:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE6hGdAPn8ivG+IM2dvBCMHjSL0HqPWe2NqVfeRaRUQshlKS4+fAYAChKt4rL6Pa7ACqYITMxHtLUedUDMdUrg= X-Received: by 2002:a05:651c:c8a:b0:36c:259a:c921 with SMTP id 38308e7fff4ca-36f7e980d5amr58438351fa.13.1759237588502; Tue, 30 Sep 2025 06:06:28 -0700 (PDT) MIME-Version: 1.0 References: <20250520164025.2055721-1-bruce.richardson@intel.com> <20250722140316.3568603-1-bruce.richardson@intel.com> In-Reply-To: <20250722140316.3568603-1-bruce.richardson@intel.com> From: David Marchand Date: Tue, 30 Sep 2025 15:06:14 +0200 X-Gm-Features: AS18NWDJknUmkNlYUzCrktihaTvK3ikXVA-FsvISE3wrRV0AjJHmRsP6clP1YEg Message-ID: Subject: Re: [PATCH v6 0/9] rework EAL argument parsing To: Bruce Richardson Cc: dev@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 44ky2mGVKBL-av-laGstHQLqsqzpA-Kiq2oEqfrrW9g_1759237589 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 Hello Bruce, On Tue, 22 Jul 2025 at 16:04, Bruce Richardson wrote: > > When processing cmdline arguments in DPDK, we always do so with very > little context. So, for example, when processing the "-l" flag, we have > no idea whether there will be later a --proc-type=secondary flag. We > have all sorts of post-arg-processing checks in place to try and catch > these scenarios. > > To improve this situation, this patchset tries to simplify the handling > of argument processing, by explicitly doing an initial pass to collate > all arguments into a structure. Thereafter, the actual arg parsing is > done in a fixed order, meaning that e.g. when processing the > --main-lcore flag, we have already processed the service core flags. We > also can far quicker and easier check for conflicting options, since > they can all be checked for NULL/non-NULL in the arg structure > immediately after the struct has been populated. > > To do the initial argument gathering, this RFC uses the existing > argparse library in DPDK. With recent changes, and two additional > patches at the start of this set, this library now meets our needs for > EAL argument parsing and allows us to not need to do direct getopt > argument processing inside EAL at all. > > An additional benefit of this work is that the argument parsing for EAL > is much more centralised into common options and the options list file. > This single list with ifdefs makes it clear to the viewer what options > are common across OS's, vs what are unix-only or linux-only. I sent a few comments, but the series looks good to me up to HEAD~2. I am still pondering on the new options as I don't see the need for multiple options. I have in mind the case when (containerised) dpdk applications are started with no EAL core options, and they rely on cpu affinity and EAL discovery. For them, if we don't want to touch the default behavior of the -l option, a simple -L ( / --lcore-remap) option would be enough. And this -L option could accept an optional base value for remapping to a certain range for multiprocess? -- David Marchand