On Wed, Nov 23, 2022 at 8:03 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:

Again, apologies for removing recipients in my earlier reply.

 

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

 

On Fri, Nov 18, 2022 at 8:00 AM Juraj Linkeš <juraj.linkes@pantheon.tech> 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 verify 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. 
 

<snip>

+    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 = self.create_session("dpdk_kill")
+        self.dpdk_prefix_list = []
+
+    def create_eal_parameters(
+        self,
+        fixed_prefix: bool = False,
+        core_filter_specifier: CPUAmount | CPUList = CPUAmount(),
+        ascending_cores: bool = True,
+        prefix: str = "",
+        no_pci: bool = False,
+        vdevs: list[str] = 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.