From patchwork Mon May 10 10:26:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 12247549 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BDA4C433B4 for ; Mon, 10 May 2021 10:32:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6C16061921 for ; Mon, 10 May 2021 10:32:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231955AbhEJKdZ (ORCPT ); Mon, 10 May 2021 06:33:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:40012 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231963AbhEJKbW (ORCPT ); Mon, 10 May 2021 06:31:22 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EBEEC6192E; Mon, 10 May 2021 10:27:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620642444; bh=JHrumuJOe6FPSOXtxa7jrYaoJY9vbi6C0ga6OBO3OOQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bL2KjOazqKkB/5uqQ6a7DcObXQdOwnE8many6Ux8uAV4pKAXxcfTh0shx1DCBcFuT g1lD/h/w0X9CsEh0rwaSWVRjoolnSgOCkNCk5tZwkbOtqd4ubHT8VuLAiURPs4vO5C 6gv9LA6qm4U+Bbecq83YbkmzlH0KMfMjDUii8mehv5pojenHER/r8luDVLpT0oiXbW 5cz5ySTQwKYP0ethnSTnKPbxg/CqB/NlKJajV4UwuqsqDH7NLJ2tnNOFZ/UkwYn1q3 R8drqmkhvK8CAI0UTgJJRdUNlGNpZCNkeZ6I4ab3qLensGw/t/ewFVckEzqUjHNxzC 1EknBCAbT/WYw== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1lg38E-000UQW-0G; Mon, 10 May 2021 12:27:22 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , "David S. Miller" , "Jonathan Corbet" , Jakub Kicinski , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 34/53] docs: networking: scaling.rst: avoid using UTF-8 chars Date: Mon, 10 May 2021 12:26:46 +0200 Message-Id: <170ea81ea77d8b381a0506e7848754aeea7fb7c5.1620641727.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK - U+201c ('“'): LEFT DOUBLE QUOTATION MARK - U+201d ('”'): RIGHT DOUBLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab --- Documentation/networking/scaling.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/networking/scaling.rst b/Documentation/networking/scaling.rst index 3d435caa3ef2..e1a0c88193fa 100644 --- a/Documentation/networking/scaling.rst +++ b/Documentation/networking/scaling.rst @@ -30,7 +30,7 @@ queues to distribute processing among CPUs. The NIC distributes packets by applying a filter to each packet that assigns it to one of a small number of logical flows. Packets for each flow are steered to a separate receive queue, which in turn can be processed by separate CPUs. This mechanism is -generally known as “Receive-side Scaling” (RSS). The goal of RSS and +generally known as "Receive-side Scaling" (RSS). The goal of RSS and the other scaling techniques is to increase performance uniformly. Multi-queue distribution can also be used for traffic prioritization, but that is not the focus of these techniques. @@ -46,7 +46,7 @@ indirection table and reading the corresponding value. Some advanced NICs allow steering packets to queues based on programmable filters. For example, webserver bound TCP port 80 packets -can be directed to their own receive queue. Such “n-tuple” filters can +can be directed to their own receive queue. Such "n-tuple" filters can be configured from ethtool (--config-ntuple). @@ -114,7 +114,7 @@ RSS. Being in software, it is necessarily called later in the datapath. Whereas RSS selects the queue and hence CPU that will run the hardware interrupt handler, RPS selects the CPU to perform protocol processing above the interrupt handler. This is accomplished by placing the packet -on the desired CPU’s backlog queue and waking up the CPU for processing. +on the desired CPU's backlog queue and waking up the CPU for processing. RPS has some advantages over RSS: 1) it can be used with any NIC @@ -128,20 +128,20 @@ netif_receive_skb(). These call the get_rps_cpu() function, which selects the queue that should process a packet. The first step in determining the target CPU for RPS is to calculate a -flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash +flow hash over the packet's addresses or ports (2-tuple or 4-tuple hash depending on the protocol). This serves as a consistent hash of the associated flow of the packet. The hash is either provided by hardware or will be computed in the stack. Capable hardware can pass the hash in the receive descriptor for the packet; this would usually be the same hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in skb->hash and can be used elsewhere in the stack as a hash of the -packet’s flow. +packet's flow. Each receive hardware queue has an associated list of CPUs to which RPS may enqueue packets for processing. For each received packet, an index into the list is computed from the flow hash modulo the size of the list. The indexed CPU is the target for processing the packet, -and the packet is queued to the tail of that CPU’s backlog queue. At +and the packet is queued to the tail of that CPU's backlog queue. At the end of the bottom half routine, IPIs are sent to any CPUs for which packets have been queued to their backlog queue. The IPI wakes backlog processing on the remote CPU, and any queued packets are then processed @@ -298,7 +298,7 @@ CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table and the rps_dev_flow table of the queue that the packet was received on are compared. If the desired CPU for the flow (found in the rps_sock_flow table) matches the current CPU (found in the rps_dev_flow -table), the packet is enqueued onto that CPU’s backlog. If they differ, +table), the packet is enqueued onto that CPU's backlog. If they differ, the current CPU is updated to match the desired CPU if one of the following is true: @@ -356,7 +356,7 @@ the application thread consuming the packets of each flow is running. Accelerated RFS should perform better than RFS since packets are sent directly to a CPU local to the thread consuming the data. The target CPU will either be the same CPU where the application runs, or at least a CPU -which is local to the application thread’s CPU in the cache hierarchy. +which is local to the application thread's CPU in the cache hierarchy. To enable accelerated RFS, the networking stack calls the ndo_rx_flow_steer driver function to communicate the desired hardware @@ -369,7 +369,7 @@ The hardware queue for a flow is derived from the CPU recorded in rps_dev_flow_table. The stack consults a CPU to hardware queue map which is maintained by the NIC driver. This is an auto-generated reverse map of the IRQ affinity table shown by /proc/interrupts. Drivers can use -functions in the cpu_rmap (“CPU affinity reverse map”) kernel library +functions in the cpu_rmap ("CPU affinity reverse map") kernel library to populate the map. For each CPU, the corresponding queue in the map is set to be one whose processing CPU is closest in cache locality. From patchwork Mon May 10 10:26:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 12247551 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 697E4C43461 for ; Mon, 10 May 2021 10:32:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3712661934 for ; Mon, 10 May 2021 10:32:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232222AbhEJKdp (ORCPT ); Mon, 10 May 2021 06:33:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:40400 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231364AbhEJKbk (ORCPT ); Mon, 10 May 2021 06:31:40 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id EB4A161601; Mon, 10 May 2021 10:27:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620642444; bh=jioxfYQEAZJHM7vUpkbi4bioydkL+hH7U0N0/80717Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QGxfv/dzUFDNIhEgvRwGe+4xhXIgzAhDXite3H3ABCjNV5YmUzEPbL2jpPWhcQVZp 7JJXhGxerlhHo+IKC9tXpUm1QXFRiSVATJQcmgf+tXkF4ow7MENHh7KIiTlSiOZy0F 7O30u1MBLDKNT0bAjucVe80toRflL50xNyMU+Kq4nMjkS+OXcf+ghxD/SzM8WLjdTx h0NGUYXmAzN1L7Me/rcwzu0yzqB/6pvnu5YsYPcLfSXrDq60T/4cJUshKKNWsuoulH rgUdSunGMQ0znLFtNz6WF5TKcjT5G76BvfMQGntU2bpmQE8iJltrNZxRWYVnqU+KiT aTtizOWPvw7gg== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1lg38E-000UQa-1q; Mon, 10 May 2021 12:27:22 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , "David S. Miller" , "Jonathan Corbet" , Jakub Kicinski , Jiri Pirko , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 35/53] docs: networking: devlink: devlink-dpipe.rst: avoid using UTF-8 chars Date: Mon, 10 May 2021 12:26:47 +0200 Message-Id: X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab --- Documentation/networking/devlink/devlink-dpipe.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/networking/devlink/devlink-dpipe.rst b/Documentation/networking/devlink/devlink-dpipe.rst index af37f250df43..2df7cbf1ba70 100644 --- a/Documentation/networking/devlink/devlink-dpipe.rst +++ b/Documentation/networking/devlink/devlink-dpipe.rst @@ -52,7 +52,7 @@ purposes as a standard complementary tool. The system's view from ``devlink-dpipe`` should change according to the changes done by the standard configuration tools. -For example, it’s quite common to implement Access Control Lists (ACL) +For example, it's quite common to implement Access Control Lists (ACL) using Ternary Content Addressable Memory (TCAM). The TCAM memory can be divided into TCAM regions. Complex TC filters can have multiple rules with different priorities and different lookup keys. On the other hand hardware From patchwork Mon May 10 10:26:48 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 12247609 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88851C43600 for ; Mon, 10 May 2021 10:35:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 630CD6199B for ; Mon, 10 May 2021 10:35:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232377AbhEJKgc (ORCPT ); Mon, 10 May 2021 06:36:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:33952 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231391AbhEJKcd (ORCPT ); Mon, 10 May 2021 06:32:33 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9F7D56188B; Mon, 10 May 2021 10:27:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620642444; bh=VcaQSZIsq7mD+wAS9jpIB7+FO3hpRfDHG83wwmYCZVA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g2w1p1MXnNawAC5FuZnuQWC5U5XbTgql+7Ar3t5rOJMsHfJty8gWY/iSptt3rjqy/ RK3rRhHgxeZgnbG+ASWaE9SCSX5s2ax0K4RoQtu+WfsQGm8MLnitowI3ZveX8nCVq2 YPx6Y+5pVSIVLUqX1K+VU5+RRkOxKQKNu8hxH21cYpSI/MWGyC+CDne4aZ7XsH/PWI hUXY35hCqq0pLyocCTK/24BhfVcftbK8W5GIfORQxM0OM5KeZwJr8zs1IZfTOjLN3O 1LyJHoUdCqdWAC84g8Lke4AV2E+ftaVGwA+WVDuVktvxKZ97l6j70AQCK0mwi6FIbD +dFms8gtkxaEA== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1lg38E-000UQe-3f; Mon, 10 May 2021 12:27:22 +0200 From: Mauro Carvalho Chehab To: Linux Doc Mailing List Cc: Mauro Carvalho Chehab , "David S. Miller" , "Jonathan Corbet" , Jakub Kicinski , Jeff Kirsher , Jesse Brandeburg , Shannon Nelson , Tony Nguyen , intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: [PATCH 36/53] docs: networking: device_drivers: avoid using UTF-8 chars Date: Mon, 10 May 2021 12:26:48 +0200 Message-Id: <9d14421bef0641bb1a45dbf87865b0cd361f64d6.1620641727.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+00a0 (' '): NO-BREAK SPACE - U+2013 ('–'): EN DASH - U+2018 ('‘'): LEFT SINGLE QUOTATION MARK - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab --- .../device_drivers/ethernet/intel/i40e.rst | 12 ++++++------ .../device_drivers/ethernet/intel/iavf.rst | 6 +++--- .../device_drivers/ethernet/netronome/nfp.rst | 12 ++++++------ 3 files changed, 15 insertions(+), 15 deletions(-) diff --git a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst index 8a9b18573688..64024c77c9ca 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/i40e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst @@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the driver. To re-enable ATR, the sideband can be disabled with the ethtool -K option. For example:: - ethtool –K [adapter] ntuple [off|on] + ethtool -K [adapter] ntuple [off|on] If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is @@ -466,7 +466,7 @@ network. PTP support varies among Intel devices that support this driver. Use "ethtool -T " to get a definitive list of PTP capabilities supported by the device. -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as @@ -523,8 +523,8 @@ of a port's bandwidth (should it be available). The sum of all the values for Maximum Bandwidth is not restricted, because no more than 100% of a port's bandwidth can ever be used. -NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions -per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says +NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions +per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says "add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than 64 virtual functions (VFs). @@ -680,7 +680,7 @@ queues: for each tc, @ (e.g. queues 16@0 16@16 assigns 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total number of queues for all tcs is 64 or number of cores, whichever is lower.) -hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware +hw 1 mode channel: 'channel' with 'hw' set to 1 is a new new hardware offload mode in mqprio that makes full use of the mqprio options, the TCs, the queue configurations, and the QoS parameters. @@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates. Totals must be equal or less than port speed. For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network -monitoring tools such as ifstat or sar –n DEV [interval] [number of samples] +monitoring tools such as ifstat or sar -n DEV [interval] [number of samples] 2. Enable HW TC offload on interface:: diff --git a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst index 52e037b11c97..25e98494b385 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/iavf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst @@ -113,7 +113,7 @@ which the AVF is associated. The following are base mode features: - AVF device ID - HW mailbox is used for VF to PF communications (including on Windows) -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as @@ -171,7 +171,7 @@ queues: for each tc, @ (e.g. queues 16@0 16@16 assigns 16 queues to tc0 at offset 0 and 16 queues to tc1 at offset 16. Max total number of queues for all tcs is 64 or number of cores, whichever is lower.) -hw 1 mode channel: ‘channel’ with ‘hw’ set to 1 is a new new hardware +hw 1 mode channel: 'channel' with 'hw' set to 1 is a new new hardware offload mode in mqprio that makes full use of the mqprio options, the TCs, the queue configurations, and the QoS parameters. @@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates. Totals must be equal or less than port speed. For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network -monitoring tools such as ifstat or sar –n DEV [interval] [number of samples] +monitoring tools such as ifstat or sar -n DEV [interval] [number of samples] NOTE: Setting up channels via ethtool (ethtool -L) is not supported when the diff --git a/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst index ada611fb427c..949c036e8667 100644 --- a/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst +++ b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst @@ -62,14 +62,14 @@ actual firmware files in application-named subdirectories in $ tree /lib/firmware/netronome/ /lib/firmware/netronome/ ├── bpf - │   ├── nic_AMDA0081-0001_1x40.nffw - │   └── nic_AMDA0081-0001_4x10.nffw + │ ├── nic_AMDA0081-0001_1x40.nffw + │ └── nic_AMDA0081-0001_4x10.nffw ├── flower - │   ├── nic_AMDA0081-0001_1x40.nffw - │   └── nic_AMDA0081-0001_4x10.nffw + │ ├── nic_AMDA0081-0001_1x40.nffw + │ └── nic_AMDA0081-0001_4x10.nffw ├── nic - │   ├── nic_AMDA0081-0001_1x40.nffw - │   └── nic_AMDA0081-0001_4x10.nffw + │ ├── nic_AMDA0081-0001_1x40.nffw + │ └── nic_AMDA0081-0001_4x10.nffw ├── nic_AMDA0081-0001_1x40.nffw -> bpf/nic_AMDA0081-0001_1x40.nffw └── nic_AMDA0081-0001_4x10.nffw -> bpf/nic_AMDA0081-0001_4x10.nffw