From patchwork Fri Nov 4 23:33:12 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Ajit Khaparde X-Patchwork-Id: 119502 X-Patchwork-Delegate: ajit.khaparde@broadcom.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 37644A00C5; Sat, 5 Nov 2022 00:33:23 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D233F40691; Sat, 5 Nov 2022 00:33:22 +0100 (CET) Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by mails.dpdk.org (Postfix) with ESMTP id 9A72E4067C for ; Sat, 5 Nov 2022 00:33:20 +0100 (CET) Received: by mail-qv1-f43.google.com with SMTP id i12so4276420qvs.2 for ; Fri, 04 Nov 2022 16:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=pZZQq1VU1uvY1SSMDb/r6vTn6Lnv55ZLFW44bUiywyw=; b=gpBI5fWxZkXA5JE5pcU7zWeYNbjNrHDn+Th4NVFQPFFjXD1wX1FWLdERg/MoJxJlT5 JEMhP0kUKBFUimC1iRH4vZznXTKEKp0YWDSBtYigy44ZbZuWBJ2NIpOlA2OSHX/s2FtT +QEAa4E3zSqgCTENPSHA4h/aM1+0P30fyOhcQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pZZQq1VU1uvY1SSMDb/r6vTn6Lnv55ZLFW44bUiywyw=; b=SvdOWsVQ2jmj4/6UIo86f3hpYIGJURKBIdorPEpTfEIEruaIwJ7v6jcUmsmcmRwlhK WCNOiMFHBcr11jRqagxllZHV4wnyb0Rb2xdaM7sAYoVSv4an3kB/nKXudeHcpMIPfd89 gw3uJKCm8A3kVYOYkJ3T0Cc8zwnzItdtloA/GnLtgPmSkH7IWxRcxhP05kJTLzHUCPyM EzqotD5MW63Zd8v0zQFvuGZ2cM4spPrUGqfPBj9AylaNG6uQH+Y3A8y4glzC75pjbziA +lyJQFEbMrWK4W/EW7qFPCXJwIEPUdeYCQvLTD8GY+HYpET3gSJstBCl7xaq1VEc7Ok3 RYow== X-Gm-Message-State: ACrzQf2dD1hyCjP8ZxHVHhPIS7WYbya0PATLezHYex7KQVznj9LtKrJu ll9J+V4utzjHn5knnOcUvxv5edYzeNsHaRXJKw8Cn+dPrEiexBAlYGWbgEmfZY9KHsP/gvryMPR piJaK4CEzv683slI5tCT1/V/1R3cJMCsrdnu3VMNxTlixVFxwQX1BKmRQuSpMQuw= X-Google-Smtp-Source: AMsMyM6r8OWcznyqWJOMT/a9+Xlur0QR2cVsiJCXBe1YX/GMDkfNBiF7QJl166UYf7Vys83Trs/IhA== X-Received: by 2002:ad4:5c6c:0:b0:4bb:6675:383a with SMTP id i12-20020ad45c6c000000b004bb6675383amr34745257qvh.71.1667604798975; Fri, 04 Nov 2022 16:33:18 -0700 (PDT) Received: from localhost.localdomain ([2605:a601:a780:1400:e811:7003:1029:bd57]) by smtp.gmail.com with ESMTPSA id bm22-20020a05620a199600b006bb2cd2f6d1sm390408qkb.127.2022.11.04.16.33.15 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 16:33:17 -0700 (PDT) From: Ajit Khaparde To: dev@dpdk.org Subject: [PATCH] doc: update broadcom documentation Date: Fri, 4 Nov 2022 16:33:12 -0700 Message-Id: <20221104233312.46068-1-ajit.khaparde@broadcom.com> X-Mailer: git-send-email 2.37.1 (Apple Git-137.1) MIME-Version: 1.0 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 Update Broadcom NIC documentation. Change-Id: Ife9e7604355cc48233b4fb1cc48df82653d6fada Signed-off-by: Ajit Khaparde --- doc/guides/nics/bnxt.rst | 478 +++++++++++++++++++++++---------------- 1 file changed, 284 insertions(+), 194 deletions(-) diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst index b047f0ca64..38d2dde9ac 100644 --- a/doc/guides/nics/bnxt.rst +++ b/doc/guides/nics/bnxt.rst @@ -5,12 +5,10 @@ BNXT Poll Mode Driver ===================== The Broadcom BNXT PMD (**librte_net_bnxt**) implements support for adapters -based on Ethernet controllers and SoCs belonging to the Broadcom -BCM5741X/BCM575XX NetXtreme-E® Family of Ethernet Network Controllers, -the Broadcom BCM588XX Stingray Family of Smart NIC Adapters, and the Broadcom -StrataGX® BCM5873X Series of Communications Processors. +based on Ethernet controllers belonging to the Broadcom +BCM5741X/BCM575XX NetXtreme-E® Family of Ethernet Network Controllers. -A complete list with links to reference material is in the Appendix section. +A complete list is in the Supported Network Adapters section. CPU Support ----------- @@ -104,8 +102,8 @@ Trusted VF By default, VFs are *not* allowed to perform privileged operations, such as modifying the VF’s MAC address in the guest. These security measures are designed to prevent possible attacks. -However, when a DPDK application can be trusted (e.g., OVS-DPDK, here), these -operations performed by a VF would be legitimate and can be allowed. +However, when a DPDK application can be trusted (e.g., OVS-DPDK, `here `_), these +operations performed by a VF would be legitimate and better be allowed. To enable VF to request "trusted mode," a new trusted VF concept was introduced in Linux kernel 4.4 and allowed VFs to become “trusted” and perform some @@ -122,12 +120,12 @@ Note that control commands, e.g., ethtool, will work via the kernel PF driver, Operations supported by trusted VF: * MAC address configuration +* Promiscuous mode setting * Flow rule creation Operations *not* supported by trusted VF: * Firmware upgrade -* Promiscuous mode setting Running on PF ~~~~~~~~~~~~~ @@ -240,7 +238,8 @@ filtering on MAC address used to accept packets. .. code-block:: console testpmd> show port (port_id) macs - testpmd> mac_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX) + testpmd> mac_addr add port_id XX:XX:XX:XX:XX:XX + testpmd> mac_addr add port_id XX:XX:XX:XX:XX:XX Multicast MAC Filter ^^^^^^^^^^^^^^^^^^^^ @@ -251,7 +250,8 @@ filtering on multicast MAC address used to accept packets. .. code-block:: console testpmd> show port (port_id) mcast_macs - testpmd> mcast_addr (add|remove) (port_id) (XX:XX:XX:XX:XX:XX) + testpmd> mcast_addr add port_id XX:XX:XX:XX:XX:XX + testpmd> mcast_addr remove port_id XX:XX:XX:XX:XX:XX Application adds (or removes) Multicast addresses to enable (or disable) allowlist filtering to accept packets. @@ -640,63 +640,36 @@ hardware. For example, applications can offload packet classification only DPDK offers the Generic Flow API (rte_flow API) to configure hardware to perform flow processing. -Listed below are the rte_flow APIs BNXT PMD supports: - -* rte_flow_validate -* rte_flow_create -* rte_flow_destroy -* rte_flow_flush - -Host Based Flow Table Management -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Starting with 20.05 BNXT PMD supports host based flow table management. This is -a new mechanism that should allow higher flow scalability than what is currently -supported. This new approach also defines a new rte_flow parser, and mapper -which currently supports basic packet classification in the receive path. - -The feature uses a newly implemented control-plane firmware interface which -optimizes flow insertions and deletions. - -This feature is currently supported on Whitney+, Stingray and Thor devices. - -Notes ------ - -- On stopping a device port, all the flows created on a port by the - application will be flushed from the hardware and any tables maintained - by the PMD. After stopping the device port, all flows on the port become - invalid and are not represented in the system anymore. - Instead of destroying or flushing such flows an application should discard - all references to these flows and re-create the flows as required after the - port is restarted. - -- While an application is free to use the group id attribute to group flows - together using a specific criteria, the BNXT PMD currently associates this - group id to a VNIC id. One such case is grouping of flows which are filtered - on the same source or destination MAC address. This allows packets of such - flows to be directed to one or more queues associated with the VNIC id. - This implementation is supported only when TRUFLOW functionality is disabled. - -- An application can issue a VXLAN decap offload request using rte_flow API - either as a single rte_flow request or a combination of two stages. - The PMD currently supports the two stage offload design. - In this approach the offload request may come as two flow offload requests - Flow1 & Flow2. The match criteria for Flow1 is O_DMAC, O_SMAC, O_DST_IP, - O_UDP_DPORT and actions are COUNT, MARK, JUMP. The match criteria for Flow2 - is O_SRC_IP, O_DST_IP, VNI and inner header fields. - Flow1 and Flow2 flow offload requests can come in any order. If Flow2 flow - offload request comes first then Flow2 can’t be offloaded as there is - no O_DMAC information in Flow2. In this case, Flow2 will be deferred until - Flow1 flow offload request arrives. When Flow1 flow offload request is - received it will have O_DMAC information. Using Flow1’s O_DMAC, driver - creates an L2 context entry in the hardware as part of offloading Flow1. - Flow2 will now use Flow1’s O_DMAC to get the L2 context id associated with - this O_DMAC and other flow fields that are cached already at the time - of deferring Flow2 for offloading. Flow2 that arrive after Flow1 is offloaded - will be directly programmed and not cached. - -- PMD supports thread-safe rte_flow operations. +TruFlow® +^^^^^^^^ + +To fully support the generic flow offload, TruFlow was introduced in BNXT PMD. +Before TruFlow, hardware flow processing resources were mapped to and handled +by firmware. With TruFlow, hardware flow processing resources are mapped to +and handled by driver. + +Alleviating the limitations of firmware-based feature development, TruFlow +not only increases the flow offload feature velocity but also improves the +control plane performance (i.e., higher flow update rate). + +Flow APIs, Items, and Actions +----------------------------- + +BNXT PMD supports thread-safe rte_flow operations for rte_flow APIs and rich +set of flow items (i.e., matching patterns) and actions. Refer to the +"Supported APIs" section for the list of rte_flow APIs as well as flow items +and actions. + +Flow Persistency +---------------- + +On stopping a device port, all the flows created on a port by the +application will be flushed from the hardware and any tables maintained +by the PMD. After stopping the device port, all flows on the port become +invalid and are not represented in the system anymore. +Instead of destroying or flushing such flows an application should discard +all references to these flows and re-create the flows as required after the +port is restarted. Note: A VNIC represents a virtual interface in the hardware. It is a resource in the RX path of the chip and is used to setup various target actions such as @@ -704,6 +677,7 @@ RSS, MAC filtering etc. for the physical function in use. Virtual Function Port Representors ---------------------------------- + The BNXT PMD supports the creation of VF port representors for the control and monitoring of BNXT virtual function devices. Each port representor corresponds to a single virtual function of that device that is connected to a @@ -726,48 +700,6 @@ Note that currently hot-plugging of representor ports is not supported so all the required representors must be specified on the creation of the PF or the trusted VF. -Representors on Stingray SoC ----------------------------- -A representor created on X86 host typically represents a VF running in the same -X86 domain. But in case of the SoC, the application can run on the CPU complex -inside the SoC. The representor can be created on the SoC to represent a PF or a -VF running in the x86 domain. Since the representator creation requires passing -the bus:device.function of the PCI device endpoint which is not necessarily in the -same host domain, additional dev args have been added to the PMD. - -* rep_is_vf - false to indicate VF representor -* rep_is_pf - true to indicate PF representor -* rep_based_pf - Physical index of the PF -* rep_q_r2f - Logical COS Queue index for the rep to endpoint direction -* rep_q_f2r - Logical COS Queue index for the endpoint to rep direction -* rep_fc_r2f - Flow control for the representor to endpoint direction -* rep_fc_f2r - Flow control for the endpoint to representor direction - -The sample command line with the new ``devargs`` looks like this:: - - -a 0000:06:02.0,representor=[1],rep-based-pf=8,\ - rep-is-pf=1,rep-q-r2f=1,rep-fc-r2f=0,rep-q-f2r=1,rep-fc-f2r=1 - -.. code-block:: console - - dpdk-testpmd -l1-4 -n2 -a 0008:01:00.0,\ - representor=[0], rep-based-pf=8,rep-is-pf=0,rep-q-r2f=1,rep-fc-r2f=1,\ - rep-q-f2r=0,rep-fc-f2r=1 --log-level="pmd.*",8 -- -i --rxq=3 --txq=3 - -Number of flows supported -------------------------- -The number of flows that can be support can be changed using the devargs -parameter ``max_num_kflows``. The default number of flows supported is 16K each -in ingress and egress path. - -Selecting EM vs EEM -------------------- -Broadcom devices can support filter creation in the onchip memory or the -external memory. This is referred to as EM or EEM mode respectively. -The decision for internal/external EM support is based on the ``devargs`` -parameter ``max_num_kflows``. If this is set by the user, external EM is used. -Otherwise EM support is enabled with flows created in internal memory. - Application Support ------------------- @@ -850,36 +782,30 @@ DPDK implements a light-weight library to allow PMDs to be bonded together and p Vector Processing ----------------- -The BNXT PMD provides vectorized burst transmit/receive function implementations -on x86-based platforms using SSE (Streaming SIMD Extensions) and AVX2 (Advanced -Vector Extensions 2) instructions, and on Arm-based platforms using Arm Neon -Advanced SIMD instructions. Vector processing support is currently implemented -only for Intel/AMD and Arm CPU architectures. - -Vector processing provides significantly improved performance over scalar -processing. This improved performance is derived from a number of optimizations: +Vector mode provides significantly improved performance over scalar mode, using +SIMD (Single Instruction Multiple Data) instructions to operate on multiple packets +in parallel. -* Using SIMD instructions to operate on multiple packets in parallel. -* Using SIMD instructions to do more work per instruction than is possible - with scalar instructions, for example by leveraging 128-bit and 256-bi - load/store instructions or by using SIMD shuffle and permute operations. -* Batching +The BNXT PMD provides vectorized burst transmit/receive function implementations +on x86-based platforms and ARM-based platforms. The BNXT PMD supports SSE (Streaming +SIMD Extensions) and AVX2 (Advanced Vector Extensions 2) instructions for x86-based +platforms, and NEON instructions for ARM-based platforms. -  * TX: transmit completions are processed in bulk. -  * RX: bulk allocation of mbufs is used when allocating rxq buffers. +The BNXT Vector PMD is enabled in DPDK builds by default. However, the vector mode is +disabled when applying SIMD instructions does not improve the performance due to +non-uniform packet handling. TX and RX vector mode can be enabled independently +from each other, and the decision to disable vector mode is made at run-time when +the port is started. -* Simplifications enabled by not supporting chained mbufs in vector mode. -* Simplifications enabled by not supporting some stateless offloads in vector - mode: +The vector mode is disabled with TX and RX offloads. However, a limited set of offloads +can be enabled in a vector mode. Listed below are the TX and RX offloads with which the +vector mode can be enabled: -  * TX: only the following reduced set of transmit offloads is supported in - vector mode:: +  * TX offloads supported in vector mode   RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE -  * RX: only the following reduced set of receive offloads is supported in - vector mode (note that jumbo MTU is allowed only when the MTU setting - does not require `RTE_ETH_RX_OFFLOAD_SCATTER` to be enabled):: +  * RX offloads supported in vector mode   RTE_ETH_RX_OFFLOAD_VLAN_STRIP   RTE_ETH_RX_OFFLOAD_KEEP_CRC @@ -891,82 +817,246 @@ processing. This improved performance is derived from a number of optimizations:   RTE_ETH_RX_OFFLOAD_RSS_HASH   RTE_ETH_RX_OFFLOAD_VLAN_FILTER -The BNXT Vector PMD is enabled in DPDK builds by default. The decision to enable -vector processing is made at run-time when the port is started; if no transmit -offloads outside the set supported for vector mode are enabled then vector mode -transmit will be enabled, and if no receive offloads outside the set supported -for vector mode are enabled then vector mode receive will be enabled. Offload -configuration changes that impact the decision to enable vector mode are allowed -only when the port is stopped. +Note that the offload configuration changes impacting the vector mode enablement are +allowed only when the port is stopped. -Note that TX (or RX) vector mode can be enabled independently from RX (or TX) -vector mode. +Performance Report +------------------ -Appendix --------- +Broadcom DPDK performance has been reported since 19.08 release. The reports +provide not only the performance results but also test scenarios including test +topology and detailed configurations. See the reports at `DPDK performance link +`. -Supported Chipsets and Adapters -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Supported Network Adapters +-------------------------- -BCM5730x NetXtreme-C® Family of Ethernet Network Controllers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Listed below are BCM57400 and BCM57500 NetXtreme-E® family of Ethernet network +adapters. More information can be found in the +`NetXtreme® Brand section `_ of the `Broadcom website `_. -Information about Ethernet adapters in the NetXtreme family of adapters can be -found in the `NetXtreme® Brand section `_ of the `Broadcom website `_. +BCM57400 NetXtreme-E® Family of Ethernet Network Controllers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* ``M150c ... Single-port 40/50 Gigabit Ethernet Adapter`` -* ``P150c ... Single-port 40/50 Gigabit Ethernet Adapter`` -* ``P225c ... Dual-port 10/25 Gigabit Ethernet Adapter`` +PCIe NICs +^^^^^^^^^ -BCM574xx/575xx NetXtreme-E® Family of Ethernet Network Controllers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +* ``P210P .... Dual-port 10 Gigabit Ethernet Adapter`` +* ``P210TP ... Dual-port 10 Gigabit Ethernet Adapter`` +* ``P225P .... Dual-port 25 Gigabit Ethernet Adapter`` +* ``P150P .... Single-port 50 Gigabit Ethernet Adapter`` -Information about Ethernet adapters in the NetXtreme family of adapters can be -found in the `NetXtreme® Brand section `_ of the `Broadcom website `_. +OCP 2.0 NICs +^^^^^^^^^^^^ -* ``M125P .... Single-port OCP 2.0 10/25 Gigabit Ethernet Adapter`` -* ``M150P .... Single-port OCP 2.0 50 Gigabit Ethernet Adapter`` -* ``M150PM ... Single-port OCP 2.0 Multi-Host 50 Gigabit Ethernet Adapter`` -* ``M210P .... Dual-port OCP 2.0 10 Gigabit Ethernet Adapter`` -* ``M210TP ... Dual-port OCP 2.0 10 Gigabit Ethernet Adapter`` -* ``M1100G ... Single-port OCP 2.0 10/25/50/100 Gigabit Ethernet Adapter`` -* ``N150G .... Single-port OCP 3.0 50 Gigabit Ethernet Adapter`` -* ``M225P .... Dual-port OCP 2.0 10/25 Gigabit Ethernet Adapter`` -* ``N210P .... Dual-port OCP 3.0 10 Gigabit Ethernet Adapter`` -* ``N210TP ... Dual-port OCP 3.0 10 Gigabit Ethernet Adapter`` -* ``N225P .... Dual-port OCP 3.0 10/25 Gigabit Ethernet Adapter`` -* ``N250G .... Dual-port OCP 3.0 50 Gigabit Ethernet Adapter`` -* ``N410SG ... Quad-port OCP 3.0 10 Gigabit Ethernet Adapter`` -* ``N410SGBT . Quad-port OCP 3.0 10 Gigabit Ethernet Adapter`` -* ``N425G .... Quad-port OCP 3.0 10/25 Gigabit Ethernet Adapter`` -* ``N1100G ... Single-port OCP 3.0 10/25/50/100 Gigabit Ethernet Adapter`` -* ``N2100G ... Dual-port OCP 3.0 10/25/50/100 Gigabit Ethernet Adapter`` -* ``N2200G ... Dual-port OCP 3.0 10/25/50/100/200 Gigabit Ethernet Adapter`` -* ``P150P .... Single-port 50 Gigabit Ethernet Adapter`` -* ``P210P .... Dual-port 10 Gigabit Ethernet Adapter`` -* ``P210TP ... Dual-port 10 Gigabit Ethernet Adapter`` -* ``P225P .... Dual-port 10/25 Gigabit Ethernet Adapter`` +* ``M210P .... Dual-port 10 Gigabit Ethernet Adapter`` +* ``M210TP ... Dual-port 10 Gigabit Ethernet Adapter`` +* ``M125P .... Single-port 25 Gigabit Ethernet Adapter`` +* ``M225P .... Dual-port 25 Gigabit Ethernet Adapter`` +* ``M150P .... Single-port 50 Gigabit Ethernet Adapter`` +* ``M150PM ... Single-port Multi-Host 50 Gigabit Ethernet Adapter`` + +OCP 3.0 NICs +^^^^^^^^^^^^ + +* ``N210P .... Dual-port 10 Gigabit Ethernet Adapter`` +* ``N210TP ... Dual-port 10 Gigabit Ethernet Adapter`` +* ``N225P ... Dual-port 10 Gigabit Ethernet Adapter`` + +BCM57500 NetXtreme-E® Family of Ethernet Network Controllers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +PCIe NICs +^^^^^^^^^ * ``P410SG ... Quad-port 10 Gigabit Ethernet Adapter`` * ``P410SGBT . Quad-port 10 Gigabit Ethernet Adapter`` -* ``P425G .... Quad-port 10/25 Gigabit Ethernet Adapter`` -* ``P1100G ... Single-port 10/25/50/100 Gigabit Ethernet Adapter`` -* ``P2100G ... Dual-port 10/25/50/100 Gigabit Ethernet Adapter`` -* ``P2200G ... Dual-port 10/25/50/100/200 Gigabit Ethernet Adapter`` +* ``P425G .... Quad-port 25 Gigabit Ethernet Adapter`` +* ``P1100G ... Single-port 100 Gigabit Ethernet Adapter`` +* ``P2100G ... Dual-port 100 Gigabit Ethernet Adapter`` +* ``P2200G ... Dual-port 200 Gigabit Ethernet Adapter`` -BCM588xx NetXtreme-S® Family of SmartNIC Network Controllers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +OCP 2.0 NICs +^^^^^^^^^^^^ -Information about the Stingray family of SmartNIC adapters can be found in the -`Stingray® Brand section `_ of the `Broadcom website `_. +* ``M1100G ... Single-port OCP 2.0 10/25/50/100 Gigabit Ethernet Adapter`` + +OCP 3.0 NICs +^^^^^^^^^^^^ + +* ``N410SG ... Quad-port 10 Gigabit Ethernet Adapter`` +* ``N410SGBT . Quad-port 10 Gigabit Ethernet Adapter`` +* ``N425G .... Quad-port 25 Gigabit Ethernet Adapter`` +* ``N150G .... Single-port 50 Gigabit Ethernet Adapter`` +* ``N250G .... Dual-port 50 Gigabit Ethernet Adapter`` +* ``N1100G ... Single-port 100 Gigabit Ethernet Adapter`` +* ``N2100G ... Dual-port 100 Gigabit Ethernet Adapter`` +* ``N2200G ... Dual-port 200 Gigabit Ethernet Adapter`` + +Supported Firmware Versions +--------------------------- + +Shown below are Ethernet Network Adapters and their supported firmware versions +(refer to section “Supported Network Adapters” for the list of adapters): + +* ``BCM57400 NetXtreme-E® Family`` ... Firmware 219.0.0 or later +* ``BCM57500 NetXtreme-E® Family`` ... Firmware 219.0.0 or later -* ``PS225 ... Dual-port 25 Gigabit Ethernet SmartNIC`` +Shown below are DPDK LTS releases and their supported firmware versions: +* ``DPDK Release 19.11`` ... Firmware 219.0.103 or later +* ``DPDK Release 20.11`` ... Firmware 219.0.103 or later +* ``DPDK Release 21.11`` ... Firmware 221.0.101 or later -BCM5873x StrataGX® Family of Communications Processors -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Supported APIs +-------------- -These ARM-based processors target a broad range of networking applications, -including virtual CPE (vCPE) and NFV appliances, 10G service routers and -gateways, control plane processing for Ethernet switches, and network-attached -storage (NAS). +rte_eth APIs +~~~~~~~~~~~~ + +Listed below are the rte_eth functions supported: +* ``rte_eth_allmulticast_disable`` +* ``rte_eth_allmulticast_enable`` +* ``rte_eth_allmulticast_get`` +* ``rte_eth_dev_close`` +* ``rte_eth_dev_conf_get`` +* ``rte_eth_dev_configure`` +* ``rte_eth_dev_default_mac_addr_set`` +* ``rte_eth_dev_flow_ctrl_get`` +* ``rte_eth_dev_flow_ctrl_set`` +* ``rte_eth_dev_fw_version_get`` +* ``rte_eth_dev_get_eeprom`` +* ``rte_eth_dev_get_eeprom`` +* ``rte_eth_dev_get_eeprom_length`` +* ``rte_eth_dev_get_eeprom_length`` +* ``rte_eth_dev_get_module_eeprom`` +* ``rte_eth_dev_get_module_info`` +* ``rte_eth_dev_get_mtu`` +* ``rte_eth_dev_get_name_by_port rte_eth_dev_get_port_by_name`` +* ``rte_eth_dev_get_supported_ptypes`` +* ``rte_eth_dev_get_vlan_offload`` +* ``rte_eth_dev_hairpin_capability_get`` +* ``rte_eth_dev_info_get`` +* ``rte_eth_dev_infos_get`` +* ``rte_eth_dev_mac_addr_add`` +* ``rte_eth_dev_mac_addr_remove`` +* ``rte_eth_dev_macaddr_get`` +* ``rte_eth_dev_macaddrs_get`` +* ``rte_eth_dev_owner_get`` +* ``rte_eth_dev_rss_hash_conf_get`` +* ``rte_eth_dev_rss_hash_update`` +* ``rte_eth_dev_rss_reta_query`` +* ``rte_eth_dev_rss_reta_update`` +* ``rte_eth_dev_rx_intr_disable`` +* ``rte_eth_dev_rx_intr_enable`` +* ``rte_eth_dev_rx_queue_start`` +* ``rte_eth_dev_rx_queue_stop`` +* ``rte_eth_dev_set_eeprom`` +* ``rte_eth_dev_set_link_down`` +* ``rte_eth_dev_set_link_up`` +* ``rte_eth_dev_set_mc_addr_list`` +* ``rte_eth_dev_set_mtu`` +* ``rte_eth_dev_set_vlan_ether_type`` +* ``rte_eth_dev_set_vlan_offload`` +* ``rte_eth_dev_set_vlan_pvid`` +* ``rte_eth_dev_start`` +* ``rte_eth_dev_stop`` +* ``rte_eth_dev_supported_ptypes_get`` +* ``rte_eth_dev_tx_queue_start`` +* ``rte_eth_dev_tx_queue_stop`` +* ``rte_eth_dev_udp_tunnel_port_add`` +* ``rte_eth_dev_udp_tunnel_port_delete`` +* ``rte_eth_dev_vlan_filter`` +* ``rte_eth_led_off`` +* ``rte_eth_led_on`` +* ``rte_eth_link_get`` +* ``rte_eth_link_get_nowait`` +* ``rte_eth_macaddr_get`` +* ``rte_eth_macaddrs_get`` +* ``rte_eth_promiscuous_disable`` +* ``rte_eth_promiscuous_enable`` +* ``rte_eth_promiscuous_get`` +* ``rte_eth_rx_burst_mode_get`` +* ``rte_eth_rx_queue_info_get`` +* ``rte_eth_rx_queue_setup`` +* ``rte_eth_stats_get`` +* ``rte_eth_stats_reset`` +* ``rte_eth_timesync_adjust_time`` +* ``rte_eth_timesync_disable`` +* ``rte_eth_timesync_enable`` +* ``rte_eth_timesync_read_rx_timestamp`` +* ``rte_eth_timesync_read_time`` +* ``rte_eth_timesync_read_tx_timestamp`` +* ``rte_eth_timesync_write_time`` +* ``rte_eth_tx_burst_mode_get`` +* ``rte_eth_tx_queue_info_get`` +* ``rte_eth_tx_queue_setup`` +* ``rte_eth_xstats_get`` +* ``rte_eth_xstats_get_names`` + +rte_flow APIs +~~~~~~~~~~~~~ + +Listed below are the rte_flow functions supported: +* ``rte_flow_ops_get`` +* ``rte_flow_validate`` +* ``rte_flow_create`` +* ``rte_flow_destroy`` +* ``rte_flow_flush`` +* ``rte_flow_tunnel_action_decap_release`` +* ``rte_flow_tunnel_decap_set`` +* ``rte_flow_tunnel_item_release`` +* ``rte_flow_tunnel_match`` + +rte_flow Items +~~~~~~~~~~~~~~ + +Refer to “Table 1.2 rte_flow items availability in networking drivers” in +`Overview of Networking Drivers `. + +Listed below are the rte_flow items supported: + +* ``any`` +* ``eth`` +* ``gre`` +* ``icmp`` +* ``icmp6`` +* ``ipv4`` +* ``ipv6`` +* ``pf`` +* ``phy_port`` +* ``port_id`` +* ``port_representor`` +* ``represented_port`` +* ``tcp`` +* ``udp`` +* ``vf`` +* ``vlan`` +* ``vxlan`` + +rte_flow Actions +~~~~~~~~~~~~~~~~ -* ``StrataGX BCM58732 ... Octal-Core 3.0GHz 64-bit ARM®v8 Cortex®-A72 based SoC`` +Refer to “Table 1.3 rte_flow actions availability in networking drivers” in +`Overview of Networking Drivers `. + +Listed below are the rte_flow actions supported: + +* ``count`` +* ``dec_ttl`` +* ``drop`` +* ``of_pop_vlan`` +* ``of_push_vlan`` +* ``of_set_vlan_pcp`` +* ``of_set_vlan_vid`` +* ``pf`` +* ``phy_port`` +* ``port_id`` +* ``port_representor`` +* ``represented_port`` +* ``rss`` +* ``set_ipv4_dst`` +* ``set_ipv4_src`` +* ``set_tp_dst`` +* ``set_tp_src`` +* ``vf`` +* ``vxlan_decap`` +* ``vxlan_encap``