X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fnics%2Fbnxt.rst;h=2540ddd5c2f5b565516b060220b6af73f00610dc;hb=b94c709decbe39582c68cf3605745b60a4f7985a;hp=6ff75d0a25e965d6348c51e6892ff7e8ac077bae;hpb=398358341419ce2666fec38eff8fff98d5be5941;p=dpdk.git diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst index 6ff75d0a25..2540ddd5c2 100644 --- a/doc/guides/nics/bnxt.rst +++ b/doc/guides/nics/bnxt.rst @@ -385,7 +385,7 @@ The application enables multiple TX and RX queues when it is started. .. code-block:: console -   testpmd -l 1,3,5 --master-lcore 1 --txq=2 –rxq=2 --nb-cores=2 +   testpmd -l 1,3,5 --main-lcore 1 --txq=2 –rxq=2 --nb-cores=2 **TSS** @@ -565,9 +565,6 @@ The BNXT PMD supports a PTP client application to communicate with a PTP master clock using DPDK IEEE1588 APIs. Note that the PTP client application needs to run on PF and vector mode needs to be disabled. -For the PTP time synchronization support, the BNXT PMD must be compiled with -``CONFIG_RTE_LIBRTE_IEEE1588=y`` (this compilation flag is currently pending). - .. code-block:: console testpmd> set fwd ieee1588 // enable IEEE 1588 mode @@ -612,7 +609,7 @@ Basic stats include: * oerrors By default, per-queue stats for 16 queues are supported. For more than 16 -queues, BNXT PMD should be compiled with ``CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS`` +queues, BNXT PMD should be compiled with ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` set to the desired number of queues. Extended Stats @@ -688,6 +685,94 @@ optimizes flow insertions and deletions. This is a tech preview feature, and is disabled by default. It can be enabled using bnxt devargs. For ex: "-w 0000:0d:00.0,host-based-truflow=1”. +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. + +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 +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 +VF. When there is no hardware flow offload, each packet transmitted by the VF +will be received by the corresponding representor. Similarly each packet that is +sent to a representor will be received by the VF. Applications can take +advantage of this feature when SRIOV is enabled. The representor will allow the +first packet that is transmitted by the VF to be received by the DPDK +application which can then decide if the flow should be offloaded to the +hardware. Once the flow is offloaded in the hardware, any packet matching the +flow will be received by the VF while the DPDK application will not receive it +any more. The BNXT PMD supports creation and handling of the port representors +when the PMD is initialized on a PF or trusted-VF. The user can specify the list +of VF IDs of the VFs for which the representors are needed by using the +``devargs`` option ``representor``.:: + + -w DBDF,representor=[0,1,4] + +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:: + + -w 0000:06:02.0,host-based-truflow=1,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 + + testpmd -l1-4 -n2 -w 0008:01:00.0,host-based-truflow=1,\ + 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 -------------------