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 5D08445460; Fri, 14 Jun 2024 20:11:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4A448427CB; Fri, 14 Jun 2024 20:11:45 +0200 (CEST) Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by mails.dpdk.org (Postfix) with ESMTP id 675C7427B8 for ; Fri, 14 Jun 2024 20:11:43 +0200 (CEST) Received: by mail-pg1-f169.google.com with SMTP id 41be03b00d2f7-6fb2f398423so1624551a12.0 for ; Fri, 14 Jun 2024 11:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1718388702; x=1718993502; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LdgQXlvP7ML+OlWVsyZYyrMCb5XGCHc0QoNlONdapHI=; b=POOTZpq2lvyCoihiIzqhRQAFRodLqIy01/7pmM+xfZsd6uqlJChF62HsGzR0LahrNx P/1UDMsYDB88eESu+U2mIunFZ7Gf8262uEo0VeGa1zCgl8nmBB+4rOTM6Z+oml/ShpWL 4APxG4huoKt7feiIffyI4WZKmPf9jfbRtGoB8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718388702; x=1718993502; h=content-transfer-encoding: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=LdgQXlvP7ML+OlWVsyZYyrMCb5XGCHc0QoNlONdapHI=; b=f/U6l+P5WHX7zQYcTJs/YuarxGHjTd2W4srjWzbdPyYspzC8CtSCQjSYwOufxyXdbl FBca+sadPLjay7re71/Ao2ZeYtxHTJ79C5z9RzN6Ts3wgciLTVKxliKOO0i1FmCx0CWw 9te4QQTY3WQGP3Z/mvuyAxSG6CpmQLc1RatMZSH4RbW7FXnefOg3K2rcuQ4CKMx0Azex O6bk4VnITIwMVe14sNGP2Jn+4P4ZWp0gZzSsmn24Ly8q8fjobslj4ErUfIm38hacxkJG hi5m3lFapeg5NT5faaSvXNP3XbAzgMfWn42eoA8LhRx34Bsd61HgMcDJJReqm/qCzJuj pblw== X-Forwarded-Encrypted: i=1; AJvYcCVpDsrP0BMPgdINZ9pvV44PT4HfduiRmiurLdO3swaH3R1Tuwj+2AaxPYHkj4ueMHIVD0Ofeb6UhIgY/X8= X-Gm-Message-State: AOJu0Yz/8l9l9ECq+NpuTf4GE7ua9M+F1XRCGDTsPW28QHtqMI9ERxFw rdp+u70zx5YCztsy8Q4m9qjeJPTxNHGG9iigB0Z2dAnFJYKoqJAbSxtr+leKuXd0ZKWIW1aJ4wM rWvc8KhZxWucfUwCZdY+IHosdlWW1ZwheNWxbIA== X-Google-Smtp-Source: AGHT+IEk/lq2UWTdqdFbqEvW0mlwwc7f2mgn9b8t3M0wk7Ab1V9hU5MygpVfwzfbLs2gCCPBek3oDbiVTujFoNx6/xs= X-Received: by 2002:a17:90a:6b07:b0:2c2:fd13:b4ff with SMTP id 98e67ed59e1d1-2c4dbb43dfemr3348240a91.39.1718388702548; Fri, 14 Jun 2024 11:11:42 -0700 (PDT) MIME-Version: 1.0 References: <20240613201831.9748-3-npratte@iol.unh.edu> <20240613201831.9748-11-npratte@iol.unh.edu> In-Reply-To: <20240613201831.9748-11-npratte@iol.unh.edu> From: Jeremy Spewock Date: Fri, 14 Jun 2024 14:11:31 -0400 Message-ID: Subject: Re: [PATCH 4/4] dts: Rework DPDK Attributes In SUT Node Config To: Nicholas Pratte Cc: Honnappa.Nagarahalli@arm.com, paul.szczepanek@arm.com, luca.vizzarro@arm.com, juraj.linkes@pantheon.tech, bruce.richardson@intel.com, probb@iol.unh.edu, dmarx@iol.unh.edu, yoan.picchi@foss.arm.com, dev@dpdk.org 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 Funny, this commit addresses a comment I had on the previous. I think it makes a lot of sense to split the EAL parameter information into a DPDK specific config that the TG doesn't have since it likely won't need it. On Thu, Jun 13, 2024 at 4:22=E2=80=AFPM Nicholas Pratte wrote: > > Rework 'lcores' and 'memory_channels' into a new 'dpdk_config' > subsection in an effort to make these attributes SUT specific; the > traffic generator, more often than not, does not need this information. > Ideally, if such information is needed, then it will be listed in the > 'traffic_generator' component in TG Node configuration. Such logic is > not introduced in this patch, but the framework can be rewritten to do > so without any implications of extreme effort. > > To make this work, use_first_core has been removed from the framework I think it makes more sense to do this in the commit where you removed it from the config as well and just completely take it out. There isn't really a need to keep it in the framework in that commit so I'd be more in favor of removing it from there entirely and then this commit won't need to since it's less relevant here. > entirely in favor of doing this within the LogicalCoreListFilter object. > Since use_first_core was only ever activated when logical core 0 was > explicitly defined, core 0 can be removed from the list of total logical > cores assuming that it was not listed within filter_specifier. > > This patch also removes 'vdevs' from 'system_under_test_node' and moves > it into 'executions.' > > Bugzilla ID: 1360 > Signed-off-by: Nicholas Pratte > > --- > diff --git a/dts/framework/testbed_model/cpu.py b/dts/framework/testbed_m= odel/cpu.py > index 9e33b2825d..0c315a0da6 100644 > --- a/dts/framework/testbed_model/cpu.py > +++ b/dts/framework/testbed_model/cpu.py > @@ -210,6 +210,8 @@ def filter(self) -> list[LogicalCore]: > Returns: > The filtered cores. > """ > + if 0 in self._lcores_to_filter: > + self._lcores_to_filter =3D self._lcores_to_filter[1:] > sockets_to_filter =3D self._filter_sockets(self._lcores_to_filte= r) > filtered_lcores =3D [] > for socket_to_filter in sockets_to_filter: > @@ -328,6 +330,9 @@ def filter(self) -> list[LogicalCore]: > Return: > The filtered logical CPU cores. > """ > + if 0 not in self._filter_specifier.lcore_list: > + self._lcores_to_filter =3D self._lcores_to_filter[1:] > + I don't really understand what these two conditionals are doing. if 0 is in the lcore_list, why do we need to omit the first value from the filter list? Or if it is in the cores to filter why do we need to remove the first element from that list? Also, is this attempting to omit core 0 in the list? I think where it appears in the list can be different depending on if the list is ascending or descending which is different depending on the EAL parameters function it seems. Regardless, can we add a comment on why this is needed? > if not len(self._filter_specifier.lcore_list): > return self._lcores_to_filter > > 2.44.0 >