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 EFA88A00C3; Mon, 28 Nov 2022 14:05:50 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 907684067E; Mon, 28 Nov 2022 14:05:50 +0100 (CET) Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by mails.dpdk.org (Postfix) with ESMTP id 6512F40150 for ; Mon, 28 Nov 2022 14:05:49 +0100 (CET) Received: by mail-pl1-f169.google.com with SMTP id 4so10102116pli.0 for ; Mon, 28 Nov 2022 05:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8zC+TpzSuSQrvaGCXlu+sjElWFdzRAlcM++Jjzrh2bw=; b=Pe7kxV5z7wL1tJObptd0gc6ywVanhLhFlZYHdETpLa+7qOAfPMX+G9OFedplh9fgaS CrYUfHg2RK5d4cYoJJaZAYQpdVmysLzc8cz9OMRAUmGpLvlWn33jEs9Tjz9xxqp/9IjM T+gDnzlbxX7kwGzdOrX/FduEtQ2Fx1O/YwdRA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=8zC+TpzSuSQrvaGCXlu+sjElWFdzRAlcM++Jjzrh2bw=; b=KMDPeB35qhZ1XuHkyitHwZx2J/DGWIRAdhGlC9n2SemaEp4uvmPqtTlWIswl+zrerp wNnkMDxp8D2mcGuDrM+SRNPzk/pR/NE62IgiD3pE4xATZ7FU+yMiNp9dqooRcU0hd+h1 jO+WQBN8YrRS84rXF/3b/teZtDahrcXp6ZRyp1MoaprS3QfMkCh6DUDb9aO0mNVw7IcO KwNmCqcc0PsqawVR4HGD3hrYDHlbjbt7mnjJjk2EcDImlXFOnV2qdG3PqTyqimpK0kl+ MrwH4KFEx4LJRrhCoODQ7AhpkfCRE8j15Z4BX0JonuThdXOTcvLOFFX4Gvd86crwWyFx 6vyw== X-Gm-Message-State: ANoB5pnTIGcmaxzHamHU9t7JgNwQ7H6U/I5MuSsIAeMl9DGRM/60vvVo 4qIEqLr43lilSltqfgRHYKMPtc6OMxWvhn7zi8EKMWiQAEZyVA== X-Google-Smtp-Source: AA0mqf68LHeN54O2Pat62mhw5vwpn/jarRrH6eFgi6OiiCrRz06UbzYtcQqF+2tfgR4ydK/otsFJegnRfOPMS7d3d98= X-Received: by 2002:a17:90a:4147:b0:214:2214:869e with SMTP id m7-20020a17090a414700b002142214869emr61990164pjg.76.1669640748422; Mon, 28 Nov 2022 05:05:48 -0800 (PST) MIME-Version: 1.0 References: <20220824162454.394285-1-juraj.linkes@pantheon.tech> <20221114165438.1133783-1-juraj.linkes@pantheon.tech> <20221114165438.1133783-5-juraj.linkes@pantheon.tech> <29978ff569e142bdae85b16972c144c0@pantheon.tech> In-Reply-To: <29978ff569e142bdae85b16972c144c0@pantheon.tech> From: Owen Hilyard Date: Mon, 28 Nov 2022 08:05:12 -0500 Message-ID: Subject: Re: [RFC PATCH v2 04/10] dts: add dpdk execution handling To: =?UTF-8?Q?Juraj_Linke=C5=A1?= Cc: "thomas@monjalon.net" , "Honnappa.Nagarahalli@arm.com" , "lijuan.tu@intel.com" , "bruce.richardson@intel.com" , "dev@dpdk.org" Content-Type: multipart/alternative; boundary="000000000000b6731405ee8787d9" 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 --000000000000b6731405ee8787d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2022 at 8:03 AM Juraj Linke=C5=A1 wrote: > Again, apologies for removing recipients in my earlier reply. > > > > *From:* Owen Hilyard > *Sent:* Monday, November 21, 2022 1:40 PM > *To:* Juraj Linke=C5=A1 > *Subject:* Re: [RFC PATCH v2 04/10] dts: add dpdk execution handling > > > > On Fri, Nov 18, 2022 at 8:00 AM Juraj Linke=C5=A1 > wrote: > > diff --git a/dts/framework/config/conf_yaml_schema.json > b/dts/framework/config/conf_yaml_schema.json > index 409ce7ac74..c59d3e30e6 100644 > --- a/dts/framework/config/conf_yaml_schema.json > +++ b/dts/framework/config/conf_yaml_schema.json > @@ -6,6 +6,12 @@ > "type": "string", > "description": "A unique identifier for a node" > }, > + "ARCH": { > + "type": "string", > + "enum": [ > + "x86_64" > > arm64 and ppc64le should probably be included here. I think that we can > focus on 64 bit arches for now. > > [Juraj] Seems safe enough. At this point it doesn't matter, but when we > have a number of testcases, we may need to revisit this (if we can't veri= fy > an architecture for example). > > > > [Owen] The reason I want this is because I want there to always be an > architecture that is not the one being developed on that developers need = to > handle properly. LoongArch might actually be a good candidate for this if > support gets merged, since to my knowledge almost no one has access to > their server-class CPUs yet. Essentially, I want to force anyone who does > something that is architecture dependent to consider other architectures, > not just have the "the entire world is x86" mentality. > > > > Alright, good to know. > > I have a semi-related point, we specify arch (and os as well) in both > build target and SUT config. Are these even going to be different? I see > cpu (or platform in meson config) being different, but not the other two > and that could simplify the config a bit. > [Owen] If I remember correctly, the older DTS has i686 (32 bit x86) support, and you might want to run i686 on an x86_64 cpu. That is the only use case I can see for differing build arch and SUT arch. The community lab doesn't have any 32 bit hardware, so any future 32 bit testing would need to happen on a 64 bit system running in a compatibility mode. > > > + def kill_cleanup_dpdk_apps(self) -> None: > + """ > + Kill all dpdk applications on the SUT. Cleanup hugepages. > + """ > + if self._dpdk_kill_session and self._dpdk_kill_session.is_alive(= ): > + # we can use the session if it exists and responds > + > self._dpdk_kill_session.kill_cleanup_dpdk_apps(self.dpdk_prefix_list) > + else: > + # otherwise, we need to (re)create it > + self._dpdk_kill_session =3D self.create_session("dpdk_kill") > + self.dpdk_prefix_list =3D [] > + > + def create_eal_parameters( > + self, > + fixed_prefix: bool =3D False, > + core_filter_specifier: CPUAmount | CPUList =3D CPUAmount(), > + ascending_cores: bool =3D True, > + prefix: str =3D "", > + no_pci: bool =3D False, > + vdevs: list[str] =3D None, > > I would prefer to have vdevs be a list of objects, even if for now that > class just takes a string in its constructor. Later on we can add > subclasses for specific vdevs that might see heavy use, such > as librte_net_pcap and crypto_openssl. > > [Juraj] Ok, this is simple enough, I'll add it. > > --000000000000b6731405ee8787d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 23, 2022 at 8:03 AM Juraj Lin= ke=C5=A1 <juraj.linkes@pantheon.tech> wrote:

Again, apologies for removing recipients in = my earlier reply.

=C2=A0

From:= Owen Hilyard <ohilyard@iol.unh.edu>
Sent: Monday, November 21, 2022 1:40 PM
To: Juraj Linke=C5=A1 <juraj.linkes@pantheon.tech>
Subject: Re: [RFC PATCH v2 04/10] dts: add dpdk execution handling

=C2=A0

On Fri, Nov 18, 2022 at= 8:00 AM Juraj Linke=C5=A1 <juraj.linkes@pantheon.tech> wrote:=

diff --git a/dts/framew= ork/config/conf_yaml_schema.json b/dts/framework/config/conf_yaml_schema.js= on
index 409ce7ac74..c59d3e30e6 100644
--- a/dts/framework/config/conf_yaml_schema.json
+++ b/dts/framework/config/conf_yaml_schema.json
@@ -6,6 +6,12 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0"type": "string",
=C2=A0 =C2=A0 =C2=A0 =C2=A0"description": "A unique identifi= er for a node"
=C2=A0 =C2=A0 =C2=A0},
+=C2=A0 =C2=A0 "ARCH": {
+=C2=A0 =C2=A0 =C2=A0 "type": "string",
+=C2=A0 =C2=A0 =C2=A0 "enum": [
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 "x86_64"

arm64 and ppc64le should probably be included here. I think that we can foc= us on 64 bit arches for now.=C2=A0

[Juraj] Seems safe enough. At this point it doesn't matter, but when we= have a number of testcases, we may need to revisit this (if we can't v= erify an architecture for example).

=C2=A0

[Owen] The reason I wan= t this is because I want there to always be an architecture that is not the= one being developed on that developers need to handle properly. LoongArch = might actually be a good candidate for this if support gets merged, since to my knowledge almost no one has acces= s to their server-class CPUs yet. Essentially, I want to force anyone who d= oes something that is architecture dependent to consider other architecture= s, not just have the "the entire world is x86" mentality.=C2=A0

=C2=A0

Alright, good to know.<= /p>

I have a semi-related point, we specify arch= (and os as well) in both build target and SUT config. Are these even going= to be different? I see cpu (or platform in meson config) being different, but not the other two and that could sim= plify the config a bit.=C2=A0


[Owen] If I remember corre= ctly, the older DTS has i686 (32 bit x86) support, and you might want to ru= n i686 on an x86_64 cpu. That is the only use case I can see for differing = build arch and SUT arch. The community lab doesn't have any 32 bit hard= ware, so any future 32 bit testing would need to happen on a 64 bit system = running in a compatibility mode.=C2=A0
=C2=A0
<= div lang=3D"SK">
=

<snip>

+=C2=A0 =C2=A0 def kill_cleanup_dpdk_apps(self) -> None:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 """
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kill all dpdk applications on the SUT. Cleanup= hugepages.
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 """
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 if self._dpdk_kill_session and self._dpdk_kill= _session.is_alive():
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # we can use the session if it e= xists and responds
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self._dpdk_kill_session.kill_cle= anup_dpdk_apps(self.dpdk_prefix_list)
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 else:
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # otherwise, we need to (re)crea= te it
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self._dpdk_kill_session =3D self= .create_session("dpdk_kill")
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 self.dpdk_prefix_list =3D []
+
+=C2=A0 =C2=A0 def create_eal_parameters(
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 self,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 fixed_prefix: bool =3D False,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 core_filter_specifier: CPUAmount | CPUList =3D= CPUAmount(),
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 ascending_cores: bool =3D True,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix: str =3D "",
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 no_pci: bool =3D False,
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 vdevs: list[str] =3D None,

I would prefer to have vdevs be a list of objects, even if for now that cla= ss just takes a string in its constructor. Later on we can add subclasses f= or specific vdevs that might see heavy use, such as=C2=A0librte_net_pcap an= d crypto_openssl.=C2=A0

[Juraj] Ok, this is simple enough, I'll add it.

--000000000000b6731405ee8787d9--