[RFC PATCH v2 04/10] dts: add dpdk execution handling

[Owen Hilyard]

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

> Again, apologies for removing recipients in my earlier reply.
>
>
>
> *From:* Owen Hilyard <ohilyard at iol.unh.edu>
> *Sent:* Monday, November 21, 2022 1:40 PM
> *To:* Juraj Linkeš <juraj.linkes at 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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20221128/1d4bd438/attachment-0001.htm>