<div dir="ltr"><div dir="ltr">On Wed, Nov 23, 2022 at 8:03 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg6114682772909123938"> <div lang="SK"> <div class="m_6114682772909123938WordSection1"> <p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Again, apologies for removing recipients in my earlier reply.<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p> <p class="MsoNormal" style="margin-left:35.4pt"><b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif"> Owen Hilyard <<a href="mailto:ohilyard@iol.unh.edu" target="_blank">ohilyard@iol.unh.edu</a>> <br> <b>Sent:</b> Monday, November 21, 2022 1:40 PM<br> <b>To:</b> Juraj Linkeš <juraj.linkes@pantheon.tech><br> <b>Subject:</b> Re: [RFC PATCH v2 04/10] dts: add dpdk execution handling<u></u><u></u></span></p> <p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p> <div> <div> <p class="MsoNormal" style="margin-left:35.4pt">On Fri, Nov 18, 2022 at 8:00 AM Juraj Linkeš <<a href="mailto:juraj.linkes@pantheon.tech" target="_blank">juraj.linkes@pantheon.tech</a>> wrote:<u></u><u></u></p> </div> <div> <blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"> <p class="MsoNormal" style="margin-left:35.4pt">diff --git a/dts/framework/config/conf_yaml_schema.json b/dts/framework/config/conf_yaml_schema.json<br> index 409ce7ac74..c59d3e30e6 100644<br> --- a/dts/framework/config/conf_yaml_schema.json<br> +++ b/dts/framework/config/conf_yaml_schema.json<br> @@ -6,6 +6,12 @@<br> "type": "string",<br> "description": "A unique identifier for a node"<br> },<br> + "ARCH": {<br> + "type": "string",<br> + "enum": [<br> + "x86_64"<br> <br> arm64 and ppc64le should probably be included here. I think that we can focus on 64 bit arches for now. <br> <br> [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).<u></u><u></u></p> </blockquote> <div> <p class="MsoNormal" style="margin-left:35.4pt"> <u></u><u></u></p> </div> <div> <p class="MsoNormal" style="margin-left:35.4pt">[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. <u></u><u></u></p> <p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p> </div> <div> <p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Alright, good to know.<u></u><u></u></span></p> <p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.</span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></p></div></div></div></div></div></div></blockquote><div><br></div><div>[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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg6114682772909123938"><div lang="SK"><div class="m_6114682772909123938WordSection1"><div><div><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u></span></p> </div> <blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"> <p class="MsoNormal" style="margin-right:0cm;margin-bottom:12pt;margin-left:35.4pt"> <snip><br> <br> + def kill_cleanup_dpdk_apps(self) -> None:<br> + """<br> + Kill all dpdk applications on the SUT. Cleanup hugepages.<br> + """<br> + if self._dpdk_kill_session and self._dpdk_kill_session.is_alive():<br> + # we can use the session if it exists and responds<br> + self._dpdk_kill_session.kill_cleanup_dpdk_apps(self.dpdk_prefix_list)<br> + else:<br> + # otherwise, we need to (re)create it<br> + self._dpdk_kill_session = self.create_session("dpdk_kill")<br> + self.dpdk_prefix_list = []<br> +<br> + def create_eal_parameters(<br> + self,<br> + fixed_prefix: bool = False,<br> + core_filter_specifier: CPUAmount | CPUList = CPUAmount(),<br> + ascending_cores: bool = True,<br> + prefix: str = "",<br> + no_pci: bool = False,<br> + vdevs: list[str] = None,<br> <br> 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. <br> <br> [Juraj] Ok, this is simple enough, I'll add it.<u></u><u></u></p> </blockquote> </div> </div> </div> </div> </div></blockquote></div></div>