X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fprog_guide%2Fpacket_framework.rst;h=3d4e3b66cc5c0f5b82906ec85164cb57658f9b4d;hb=34fd4373ce76efd0236e59397c495762c2ec9e64;hp=381f3203e2087ad5ecdb8097cc529e09006142d3;hpb=8c9a33744bf790f106084fc4fdbc7ff27bebe677;p=dpdk.git diff --git a/doc/guides/prog_guide/packet_framework.rst b/doc/guides/prog_guide/packet_framework.rst index 381f3203e2..3d4e3b66cc 100644 --- a/doc/guides/prog_guide/packet_framework.rst +++ b/doc/guides/prog_guide/packet_framework.rst @@ -1,32 +1,5 @@ -.. BSD LICENSE - Copyright(c) 2010-2014 Intel Corporation. All rights reserved. - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - * Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - * Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - * Neither the name of Intel Corporation nor the names of its - contributors may be used to endorse or promote products derived - from this software without specific prior written permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2010-2014 Intel Corporation. Packet Framework ================ @@ -125,6 +98,10 @@ Port Types | | | character device. | | | | | +---+------------------+---------------------------------------------------------------------------------------+ + | 9 | Sym_crypto | Output port used to extract DPDK Cryptodev operations from a fixed offset of the | + | | | packet and then enqueue to the Cryptodev PMD. Input port used to dequeue the | + | | | Cryptodev operations from the Cryptodev PMD and then retrieve the packets from them. | + +---+------------------+---------------------------------------------------------------------------------------+ Port Interface ~~~~~~~~~~~~~~ @@ -454,7 +431,7 @@ The possible options are: .. _table_qos_23: -.. table:: Configuration Parameters Specific to Extendible Bucket Hash Table +.. table:: Configuration Parameters Specific to Extendable Bucket Hash Table +---+---------------------------+--------------------------------------------------+ | # | Parameter | Details | @@ -576,7 +553,7 @@ either with pre-computed signature or "do-sig"). | | | | | | +---+-------------------------+------------------------------+---------------------------+-------------------------------+ | 2 | Bucket extensions array | n_buckets_ext (configurable) | 32 | This array is only created | - | | | | | for extendible bucket tables. | + | | | | | for extendable bucket tables. | | | | | | | +---+-------------------------+------------------------------+---------------------------+-------------------------------+ | 3 | Key array | n_keys | key_size (configurable) | Keys added to the hash table. | @@ -601,7 +578,7 @@ either with pre-computed signature or "do-sig"). | | | | Entry 0 stores the index (0 .. 3) of the MRU key, while entry 3 | | | | | stores the index of the LRU key. | | | | | | - | | | | For extendible bucket tables, this field represents the next | + | | | | For extendable bucket tables, this field represents the next | | | | | pointer (i.e. the pointer to the next group of 4 keys linked to | | | | | the current bucket). The next pointer is not NULL if the bucket | | | | | is currently extended or NULL otherwise. | @@ -864,7 +841,7 @@ Single Key Size Hash Tables | | | | | | +---+-------------------------+------------------------------+----------------------+------------------------------------+ | 2 | Bucket extensions array | n_buckets_ext (configurable) | *8-byte key size:* | This array is only created for | - | | | | | extendible bucket tables. | + | | | | | extendable bucket tables. | | | | | | | | | | | 64 + 4 x entry_size | | | | | | | | @@ -885,7 +862,7 @@ Single Key Size Hash Tables +===+===============+====================+===============================================================================+ | 1 | Valid | 8 | Bit X (X = 0 .. 3) is set to 1 if key X is valid or to 0 otherwise. | | | | | | - | | | | Bit 4 is only used for extendible bucket tables to help with the | + | | | | Bit 4 is only used for extendable bucket tables to help with the | | | | | implementation of the branchless logic. In this case, bit 4 is set to 1 if | | | | | next pointer is valid (not NULL) or to 0 otherwise. | | | | | | @@ -894,7 +871,7 @@ Single Key Size Hash Tables | | | | stored as array of 4 entries of 2 bytes each. Entry 0 stores the index | | | | | (0 .. 3) of the MRU key, while entry 3 stores the index of the LRU key. | | | | | | - | | | | For extendible bucket tables, this field represents the next pointer (i.e. | + | | | | For extendable bucket tables, this field represents the next pointer (i.e. | | | | | the pointer to the next group of 4 keys linked to the current bucket). The | | | | | next pointer is not NULL if the bucket is currently extended or NULL | | | | | otherwise. | @@ -1105,6 +1082,11 @@ with each table entry having its own set of enabled user actions and its own cop | | | checksum. | | | | | +---+-----------------------------------+---------------------------------------------------------------------+ + | 7 | Sym Crypto | Generate Cryptodev session based on the user-specified algorithm | + | | | and key(s), and assemble the cryptodev operation based on the | + | | | predefined offsets. | + | | | | + +---+-----------------------------------+---------------------------------------------------------------------+ Multicore Scaling ----------------- @@ -1160,9 +1142,86 @@ Typical devices with acceleration capabilities are: * Inline accelerators: NICs, switches, FPGAs, etc; -* Look-aside accelerators: chipsets, FPGAs, etc. +* Look-aside accelerators: chipsets, FPGAs, Intel QuickAssist, etc. Usually, to support a specific functional block, specific implementation of Packet Framework tables and/or ports and/or actions has to be provided for each accelerator, with all the implementations sharing the same API: pure SW implementation (no acceleration), implementation using accelerator A, implementation using accelerator B, etc. The selection between these implementations could be done at build time or at run-time (recommended), based on which accelerators are present in the system, with no application changes required. + +The Software Switch (SWX) Pipeline +---------------------------------- + +The Software Switch (SWX) pipeline is designed to combine the DPDK performance with the flexibility of the P4-16 language [1]. It can be used either by itself +to code a complete software switch or data plane application, or in combination with the open-source P4 compiler P4C [2], acting as a P4C back-end that allows +the P4 programs to be translated to the DPDK SWX API and run on multi-core CPUs. + +The main features of the SWX pipeline are: + +* Nothing is hard-wired, everything is dynamically defined: The packet headers (i.e. the network protocols), the packet meta-data, the actions, the tables + and the pipeline itself are dynamically defined instead of selected from a predefined set. + +* Instructions: The actions and the life of the packet through the pipeline are defined with instructions that manipulate the pipeline objects mentioned + above. The pipeline is the main function of the packet program, with actions as subroutines triggered by the tables. + +* Call external plugins: Extern objects and functions can be defined to call functionality that cannot be efficiently implemented with the existing + pipeline-oriented instruction set, such as: error detecting/correcting codes, cryptographic operations, meters, statistics counter arrays, heuristics, etc. + +* Better control plane interaction: Transaction-oriented table update mechanism that supports multi-table atomic updates. Multiple tables can be updated in a + single step with only the before-update and the after-update table entries visible to the packets. Alignment with the P4Runtime [3] protocol. + +* Performance: Multiple packets are in-flight within the pipeline at any moment. Each packet is owned by a different time-sharing thread in + run-to-completion, with the thread pausing before memory access operations such as packet I/O and table lookup to allow the memory prefetch to complete. + The instructions are verified and translated at initialization time with no run-time impact. The instructions are also optimized to detect and "fuse" + frequently used patterns into vector-like instructions transparently to the user. + +The main SWX pipeline components are: + +* Input and output ports: Each port instantiates a port type that defines the port operations, e.g. Ethernet device port, PCAP port, etc. The RX interface + of the input ports and the TX interface of the output ports are single packet based, with packet batching typically implemented internally by each port for + performance reasons. + +* Structure types: Each structure type is used to define the logical layout of a memory block, such as: packet headers, packet meta-data, action data stored + in a table entry, mailboxes of extern objects and functions. Similar to C language structs, each structure type is a well defined sequence of fields, with + each field having a unique name and a constant size. + +* Packet headers: Each packet typically has one or multiple headers. The headers are extracted from the input packet as part of the packet parsing operation, + which is likely executed immediately after the packet reception. As result of the extract operation, each header is logically removed from the packet, so + once the packet parsing operation is completed, the input packet is reduced to opaque payload. Just before transmission, one or several headers are pushed + in front of each output packet through the emit operation; these headers can be part of the set of headers that were previously extracted from the input + packet (and potentially modified afterwards) or some new headers whose contents is generated by the pipeline (e.g. by reading them from tables). The format + of each packet header is defined by instantiating a structure type. + +* Packet meta-data: The packet meta-data is filled in by the pipeline (e.g. by reading it from tables) or computed by the pipeline. It is not sent out unless + some of the meta-data fields are explicitly written into the headers emitted into the output packet. The format of the packet meta-data is defined by + instantiating a structure type. + +* Extern objects and functions: Used to plug into the pipeline any functionality that cannot be efficiently implemented with the existing pipeline instruction + set. Each extern object and extern function has its own mailbox, which is used to pass the input arguments to and retrieve the output arguments from the + extern object member functions or the extern function. The mailbox format is defined by instantiating a structure type. + +* Instructions: The pipeline and its actions are defined with instructions from a predefined instruction set. The instructions are used to receive and + transmit the current packet, extract and emit headers from/into the packet, read/write the packet headers, packet meta-data and mailboxes, start table + lookup operations, read the action arguments from the table entry, call extern object member functions or extern functions. See the rte_swx_pipeline.h file + for the complete list of instructions. + +* Actions: The pipeline actions are dynamically defined through instructions as opposed to predefined. Essentially, the actions are subroutines of the + pipeline program and their execution is triggered by the table lookup. The input arguments of each action are read from the table entry (in case of table + lookup hit) or the default table action (in case of table lookup miss) and are read-only; their format is defined by instantiating a structure type. The + actions have read-write access to the packet headers and meta-data. + +* Table: Each pipeline typically has one or more lookup tables. The match fields of each table are flexibly selected from the packet headers and meta-data + defined for the current pipeline. The set of table actions is flexibly selected for each table from the set of actions defined for the current pipeline. The + tables can be looked at as special pipeline operators that result in one of the table actions being called, depending on the result of the table lookup + operation. + +* Pipeline: The pipeline represents the main program that defines the life of the packet, with subroutines (actions) executed on table lookup. As packets + go through the pipeline, the packet headers and meta-data are transformed along the way. + +References: + +[1] P4-16 specification: https://p4.org/specs/ + +[2] P4-16 compiler: https://github.com/p4lang/p4c + +[3] P4Runtime specification: https://p4.org/specs/