From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 21E1345A29; Wed, 25 Sep 2024 13:28:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A88504025D; Wed, 25 Sep 2024 13:28:58 +0200 (CEST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by mails.dpdk.org (Postfix) with ESMTP id B90B4400EF for ; Wed, 25 Sep 2024 13:28:55 +0200 (CEST) Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-53659867cbdso9786056e87.3 for ; Wed, 25 Sep 2024 04:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1727263735; x=1727868535; darn=dpdk.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=C7qamsqPXsPkLVg/LYYB3tCuZJkL8xLGwlNkNhTwPO8=; b=YZSAQgfsDzk9naJBu0brUML/0/0lRGcXj8N7PggW1WwQscHRkr6wNZEHqUsls5AMYh 3jnRspsSshRGnCU4/y3Cxv8dDClRcd6zbPMCkKjujUFxlKDoIRL3mctTL3/zLkNPxQU0 brDaPhkp3CI7+z8v0eojFCgn2H3q2FFTRiN3yzA+O+q14PYdJKUs6r3bBdsmsEEmsInu qVk5MiQXKJl3mjocgOsz5W7J7lDvnctDBtG4GjzL/jTl+9c1oS5TEhd6Hyx4H7q5Do5b op34OeEdaC0a+gTIPZ0Dz5WPoK7CynRq4ecTBrlzWoJ3q5/lSsYvJeOv+TqVaFHRVjm/ S/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727263735; x=1727868535; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=C7qamsqPXsPkLVg/LYYB3tCuZJkL8xLGwlNkNhTwPO8=; b=b1Z+x1qyZLaiOI1bqq+C07x1vhW5/Hh9HYbX/Z8xJTMy/1uv0DB0jJVB3kf62NAV6l v8kaaT5nAXkngCJ3gpoYI8griZlvqcEGJJSEWvrG1BHQGGlSAPjug7ZIkpAfeyUvxMCs T4M/ohSshHw0s1iYu07gxwJZE2oqEpJPHTG/RBqdG10jG2JaWJaFbDBDuJ+NbGPuwS5U Hre2nDS/Lfa0cOKUDhRRJjTB+IyTOD5gprLjpMUXo7kpYIdW39NdKSWCFA1HAkAEgqVd uic4zNi3vcQVsw+FD/57LNpX+ln5sm034QzsVCsEfQ0QSYaSO4C7OaS6RSbUX49uz+ep WEkA== X-Gm-Message-State: AOJu0Yzcp2k8sWoGn7WEX9mSoJsuboMWyWfNNfZwOvVfESuQAeTxDf8a PgTc1qKI8B+2vZwVGzoFkcGrjIXzFJAF1eV/x4TVftqAvHhMFhJTYCiQwhi4pvg= X-Google-Smtp-Source: AGHT+IHAoNQpqEpFx/sqH9ZK+6380FdkwBvqYtlSxuXO2TqaahUVM5uJiGAgDPgVgwv3KtjhRV82KA== X-Received: by 2002:a05:6512:a8a:b0:530:dfab:9315 with SMTP id 2adb3069b0e04-5387048aae9mr2037212e87.10.1727263735113; Wed, 25 Sep 2024 04:28:55 -0700 (PDT) Received: from [192.168.200.22] ([84.245.121.62]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93930f78a1sm196231166b.161.2024.09.25.04.28.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Sep 2024 04:28:54 -0700 (PDT) Message-ID: <1bf0d2f4-a550-4b3a-b27f-31a6f8672b01@pantheon.tech> Date: Wed, 25 Sep 2024 13:28:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/5] dts: add class for virtual functions 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 References: <20240821191557.18744-1-jspewock@iol.unh.edu> <20240923184235.22582-1-jspewock@iol.unh.edu> <20240923184235.22582-4-jspewock@iol.unh.edu> Content-Language: en-US From: =?UTF-8?Q?Juraj_Linke=C5=A1?= In-Reply-To: <20240923184235.22582-4-jspewock@iol.unh.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 23. 9. 2024 20:42, jspewock@iol.unh.edu wrote: > From: Jeremy Spewock > > In DPDK applications virtual functions are treated the same as ports, > but within the framework there are benefits to differentiating the two > in order to add more metadata to VFs about where they originate from. > For this reason this patch adds a new class for handling virtual > functions that extends the Port class with some additional information > about the VF. > > Bugzilla ID: 1500 > > Signed-off-by: Jeremy Spewock > --- > dts/framework/testbed_model/port.py | 37 ++++++++++++++++++++++++++++- > 1 file changed, 36 insertions(+), 1 deletion(-) > > diff --git a/dts/framework/testbed_model/port.py b/dts/framework/testbed_model/port.py > index 817405bea4..c1d85fec2b 100644 > --- a/dts/framework/testbed_model/port.py > +++ b/dts/framework/testbed_model/port.py > @@ -27,7 +27,7 @@ class PortIdentifier: > pci: str > > > -@dataclass(slots=True) > +@dataclass This should be explained in the commit message. > class Port: > """Physical port on a node. > > @@ -80,6 +80,41 @@ def pci(self) -> str: > return self.identifier.pci > > > +@dataclass > +class VirtualFunction(Port): > + """Virtual Function (VF) on a port. > + > + DPDK applications often treat VFs the same as they do the physical ports (PFs) on the host. > + For this reason VFs are represented in the framework as a type of port with some additional > + metadata that allows the framework to more easily identify which device the VF belongs to as > + well as where the VF originated from. > + > + Attributes: > + created_by_framework: :data:`True` if this VF represents one that the DTS framework created > + on the node, :data:`False` otherwise. I had to go look in the other patches to understand why this is here. The patch split should be redone along logical lines (one patch should contain related logic, now the related logic is in basically all patches), not files (that doesn't help with review and it's also not going to result in better git history). But I figured out this is here because of cleanup. It makes more sense to me for framework to remember whether it created the port or not as opposed to port remembering it, especially when the framework is doing the cleanup and not the ports. > + pf_port: The PF that this VF was created on/gathered from. Maybe it would make more sense to store the VF ports in the PF port. If we need to use VF ports, we can just refer to the PF port which has the benefit making it easier to use the proper link between ports. And the framework can store which PF ports needs VF cleanup instead of storing which VFs needs cleaning. > + """ > + > + created_by_framework: bool = False > + pf_port: Port | None = None > + > + def __init__( > + self, node_name: str, config: PortConfig, created_by_framework: bool, pf_port: Port > + ) -> None: > + """Extends :meth:`Port.__init__` with VF specific metadata. > + > + Args: > + node_name: The name of the node the VF resides on. > + config: Configuration information about the VF. > + created_by_framework: :data:`True` if DTS created this VF, otherwise :data:`False` if > + this class represents a VF that was preexisting on the node. > + pf_port: The PF that this VF was created on/gathered from. > + """ > + super().__init__(node_name, config) > + self.created_by_framework = created_by_framework > + self.pf_port = pf_port > + > + > @dataclass(slots=True, frozen=True) > class PortLink: > """The physical, cabled connection between the ports.