On Wed, Nov 23, 2022 at 8:03 AM Juraj Linkeš <juraj.lin...@pantheon.tech>
wrote:
> Again, apologies for removing recipients in my earlier reply.
>
>
>
> *From:* Owen Hilyard <ohily...@iol.unh.edu>
> *Sent:* Monday, November 21, 2022 1:40 PM
> *To:* Juraj Linkeš <juraj.lin...@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.lin...@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.
>
>
