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).
next prev parent reply other threads:[~2024-09-25 13:29 UTC|newest]
Thread overview: 42+ 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-11-14 16:45 ` Luca Vizzarro
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-11-14 17:01 ` Luca Vizzarro
2024-09-23 18:42 ` [PATCH v4 3/5] dts: add class for virtual functions jspewock
2024-09-25 11:28 ` Juraj Linkeš
2024-11-14 17:10 ` Luca Vizzarro
2024-09-23 18:42 ` [PATCH v4 4/5] dts: add OS abstractions for creating " jspewock
2024-09-25 12:05 ` Juraj Linkeš
2024-11-14 17:29 ` Luca Vizzarro
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-11-14 17:36 ` Luca Vizzarro
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).