DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
To: jspewock@iol.unh.edu, npratte@iol.unh.edu,
	yoan.picchi@foss.arm.com, thomas@monjalon.net,
	Honnappa.Nagarahalli@arm.com, probb@iol.unh.edu,
	wathsala.vithanage@arm.com, paul.szczepanek@arm.com,
	Luca.Vizzarro@arm.com, alex.chapman@arm.com
Cc: dev@dpdk.org
Subject: Re: [PATCH v4 5/5] dts: add functions for managing VFs to Node
Date: Wed, 25 Sep 2024 15:29:03 +0200	[thread overview]
Message-ID: <b1a89d05-d93b-45ca-a0d9-08c5fd5b96b6@pantheon.tech> (raw)
In-Reply-To: <20240923184235.22582-6-jspewock@iol.unh.edu>

I'm wondering whether we should move some of the functionality to the 
Port class, such as creating VFs and related logic. I wanted to move 
update_port and such there, but I ran into problems with imports. Maybe 
if we utilize the if TYPE_CHECKING: guard the imports would work.

Seems like a lot would be simplified if we moved the VFs ports inside 
the Port class.

> diff --git a/dts/framework/testbed_model/node.py b/dts/framework/testbed_model/node.py

>   class Node(ABC):
> @@ -276,6 +277,96 @@ def _bind_port_to_driver(self, port: Port, for_dpdk: bool = True) -> None:
>               verify=True,
>           )
>   
> +    def create_virtual_functions(
> +        self, num: int, pf_port: Port, dpdk_driver: str | None = None
> +    ) -> list[VirtualFunction]:
> +        """Create virtual functions (VFs) from a given physical function (PF) on the node.
> +
> +        Virtual functions will be created if there are not any currently configured on `pf_port`.
> +        If there are greater than or equal to `num` VFs already configured on `pf_port`, those will
> +        be used instead of creating more. In order to create VFs, the PF must be bound to its
> +        kernel driver. This method will handle binding `pf_port` and any other ports in the test
> +        run that reside on the same device back to their OS drivers if this was not done already.
> +        VFs gathered in this method will be bound to `driver` if one is provided, or the DPDK
> +        driver for `pf_port` and then added to `self.ports`.
> +
> +        Args:
> +            num: The number of VFs to create. Must be greater than 0.
> +            pf_port: The PF to create the VFs on.

We should check that the passed port actually resides on this node.

> +            dpdk_driver: Optional driver to bind the VFs to after they are created. Defaults to the
> +                DPDK driver of `pf_port`.
> +
> +        Raises:
> +            InternalError: If `num` is less than or equal to 0.
> +        """
> +        if num <= 0:
> +            raise InternalError(
> +                "Method for creating virtual functions received a non-positive value."
> +            )
> +        if not dpdk_driver:
> +            dpdk_driver = pf_port.os_driver_for_dpdk
> +        # Get any other port that is on the same device which DTS is aware of
> +        all_device_ports = [
> +            p for p in self.ports if p.pci.split(".")[0] == pf_port.pci.split(".")[0]
> +        ]

Maybe we should create a PciAddress class that would process the address 
and provide useful methods, one of which we'd use here.

> +        # Ports must be bound to the kernel driver in order to create VFs from them
> +        for port in all_device_ports:
> +            self._bind_port_to_driver(port, False)
> +            # Some PMDs require the interface being up in order to make VFs

These are OS drivers, not PMDs.

> +            self.configure_port_state(port)
> +        created_vfs = self.main_session.set_num_virtual_functions(num, pf_port)
> +        # We don't need more then `num` VFs from the list
> +        vf_pcis = self.main_session.get_pci_addr_of_vfs(pf_port)[:num]
> +        devbind_info = self.main_session.send_command(
> +            f"{self.path_to_devbind_script} -s", privileged=True
> +        ).stdout

This looks like a good candidate for TextParser.

> +
> +        ret = []
> +
> +        for pci in vf_pcis:
> +            original_driver = re.search(f"{pci}.*drv=([\\d\\w-]*)", devbind_info)
> +            os_driver = original_driver[1] if original_driver else pf_port.os_driver
> +            vf_config = PortConfig(
> +                self.name, pci, dpdk_driver, os_driver, pf_port.peer.node, pf_port.peer.pci
> +            )
> +            vf_port = VirtualFunction(self.name, vf_config, created_vfs, pf_port)
> +            self.main_session.update_ports([vf_port])

This should be called after the for cycle so we only call it once. We 
can bind all VF ports after (again, preferably with just one call).



  reply	other threads:[~2024-09-25 13:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-21 19:15 [RFC PATCH v1 0/5] dts: add VFs to the framework jspewock
2024-08-21 19:15 ` [RFC PATCH v1 1/5] dts: allow binding only a single port to a different driver jspewock
2024-08-21 19:15 ` [RFC PATCH v1 2/5] dts: parameterize what ports the TG sends packets to jspewock
2024-08-21 19:15 ` [RFC PATCH v1 3/5] dts: add class for virtual functions jspewock
2024-08-21 19:15 ` [RFC PATCH v1 4/5] dts: add OS abstractions for creating " jspewock
2024-08-21 19:15 ` [RFC PATCH v1 5/5] dts: add functions for managing VFs to Node jspewock
2024-08-21 19:21 ` [RFC PATCH v2 0/5] dts: add VFs to the framework jspewock
2024-08-21 19:21 ` [RFC PATCH v2 1/5] dts: allow binding only a single port to a different driver jspewock
2024-08-21 19:21 ` [RFC PATCH v2 2/5] dts: parameterize what ports the TG sends packets to jspewock
2024-08-21 19:21 ` [RFC PATCH v2 3/5] dts: add class for virtual functions jspewock
2024-08-21 19:21 ` [RFC PATCH v2 4/5] dts: add OS abstractions for creating " jspewock
2024-08-21 19:21 ` [RFC PATCH v2 5/5] dts: add functions for managing VFs to Node jspewock
2024-08-21 19:38 ` [RFC PATCH v2 0/5] dts: add VFs to the framework jspewock
2024-08-21 19:38   ` [RFC PATCH v2 1/5] dts: allow binding only a single port to a different driver jspewock
2024-08-21 19:38   ` [RFC PATCH v2 2/5] dts: parameterize what ports the TG sends packets to jspewock
2024-08-21 19:38   ` [RFC PATCH v2 3/5] dts: add class for virtual functions jspewock
2024-08-21 19:38   ` [RFC PATCH v2 4/5] dts: add OS abstractions for creating " jspewock
2024-08-21 19:38   ` [RFC PATCH v2 5/5] dts: add functions for managing VFs to Node jspewock
2024-08-21 19:44   ` [RFC PATCH v2 0/5] dts: add VFs to the framework Jeremy Spewock
2024-08-21 21:30 ` [RFC PATCH v3 " jspewock
2024-08-21 21:30   ` [RFC PATCH v3 1/5] dts: allow binding only a single port to a different driver jspewock
2024-08-21 21:30   ` [RFC PATCH v3 2/5] dts: parameterize what ports the TG sends packets to jspewock
2024-08-21 21:30   ` [RFC PATCH v3 3/5] dts: add class for virtual functions jspewock
2024-08-21 21:30   ` [RFC PATCH v3 4/5] dts: add OS abstractions for creating " jspewock
2024-08-21 21:30   ` [RFC PATCH v3 5/5] dts: add functions for managing VFs to Node jspewock
2024-09-23 18:42 ` [PATCH v4 0/5] dts: add VFs to the framework jspewock
2024-09-23 18:42   ` [PATCH v4 1/5] dts: allow binding only a single port to a different driver jspewock
2024-09-25  8:45     ` Juraj Linkeš
2024-09-23 18:42   ` [PATCH v4 2/5] dts: parameterize what ports the TG sends packets to jspewock
2024-09-25 10:58     ` Juraj Linkeš
2024-09-23 18:42   ` [PATCH v4 3/5] dts: add class for virtual functions jspewock
2024-09-25 11:28     ` Juraj Linkeš
2024-09-23 18:42   ` [PATCH v4 4/5] dts: add OS abstractions for creating " jspewock
2024-09-25 12:05     ` Juraj Linkeš
2024-09-23 18:42   ` [PATCH v4 5/5] dts: add functions for managing VFs to Node jspewock
2024-09-25 13:29     ` Juraj Linkeš [this message]
2024-09-25  8:24   ` [PATCH v4 0/5] dts: add VFs to the framework Juraj Linkeš

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1a89d05-d93b-45ca-a0d9-08c5fd5b96b6@pantheon.tech \
    --to=juraj.linkes@pantheon.tech \
    --cc=Honnappa.Nagarahalli@arm.com \
    --cc=Luca.Vizzarro@arm.com \
    --cc=alex.chapman@arm.com \
    --cc=dev@dpdk.org \
    --cc=jspewock@iol.unh.edu \
    --cc=npratte@iol.unh.edu \
    --cc=paul.szczepanek@arm.com \
    --cc=probb@iol.unh.edu \
    --cc=thomas@monjalon.net \
    --cc=wathsala.vithanage@arm.com \
    --cc=yoan.picchi@foss.arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).