app/testpmd: add flow queue pull operation
[dpdk.git] / doc / guides / prog_guide / packet_framework.rst
1 ..  SPDX-License-Identifier: BSD-3-Clause
2     Copyright(c) 2010-2014 Intel Corporation.
3
4 Packet Framework
5 ================
6
7 Design Objectives
8 -----------------
9
10 The main design objectives for the DPDK Packet Framework are:
11
12 *   Provide standard methodology to build complex packet processing pipelines.
13     Provide reusable and extensible templates for the commonly used pipeline functional blocks;
14
15 *   Provide capability to switch between pure software and hardware-accelerated implementations for the same pipeline functional block;
16
17 *   Provide the best trade-off between flexibility and performance.
18     Hardcoded pipelines usually provide the best performance, but are not flexible,
19     while developing flexible frameworks is never a problem, but performance is usually low;
20
21 *   Provide a framework that is logically similar to Open Flow.
22
23 Overview
24 --------
25
26 Packet processing applications are frequently structured as pipelines of multiple stages,
27 with the logic of each stage glued around a lookup table.
28 For each incoming packet, the table defines the set of actions to be applied to the packet,
29 as well as the next stage to send the packet to.
30
31 The DPDK Packet Framework minimizes the development effort required to build packet processing pipelines
32 by defining a standard methodology for pipeline development,
33 as well as providing libraries of reusable templates for the commonly used pipeline blocks.
34
35 The pipeline is constructed by connecting the set of input ports with the set of output ports
36 through the set of tables in a tree-like topology.
37 As result of lookup operation for the current packet in the current table,
38 one of the table entries (on lookup hit) or the default table entry (on lookup miss)
39 provides the set of actions to be applied on the current packet,
40 as well as the next hop for the packet, which can be either another table, an output port or packet drop.
41
42 An example of packet processing pipeline is presented in :numref:`figure_figure32`:
43
44 .. _figure_figure32:
45
46 .. figure:: img/figure32.*
47
48    Example of Packet Processing Pipeline where Input Ports 0 and 1
49    are Connected with Output Ports 0, 1 and 2 through Tables 0 and 1
50
51
52 Port Library Design
53 -------------------
54
55 Port Types
56 ~~~~~~~~~~
57
58 :numref:`table_qos_19` is a non-exhaustive list of ports that can be implemented with the Packet Framework.
59
60 .. _table_qos_19:
61
62 .. table:: Port Types
63
64    +---+------------------+---------------------------------------------------------------------------------------+
65    | # | Port type        | Description                                                                           |
66    |   |                  |                                                                                       |
67    +===+==================+=======================================================================================+
68    | 1 | SW ring          | SW circular buffer used for message passing between the application threads. Uses     |
69    |   |                  | the DPDK rte_ring primitive. Expected to be the most commonly used type of            |
70    |   |                  | port.                                                                                 |
71    |   |                  |                                                                                       |
72    +---+------------------+---------------------------------------------------------------------------------------+
73    | 2 | HW ring          | Queue of buffer descriptors used to interact with NIC, switch or accelerator ports.   |
74    |   |                  | For NIC ports, it uses the DPDK rte_eth_rx_queue or rte_eth_tx_queue                  |
75    |   |                  | primitives.                                                                           |
76    |   |                  |                                                                                       |
77    +---+------------------+---------------------------------------------------------------------------------------+
78    | 3 | IP reassembly    | Input packets are either IP fragments or complete IP datagrams. Output packets are    |
79    |   |                  | complete IP datagrams.                                                                |
80    |   |                  |                                                                                       |
81    +---+------------------+---------------------------------------------------------------------------------------+
82    | 4 | IP fragmentation | Input packets are jumbo (IP datagrams with length bigger than MTU) or non-jumbo       |
83    |   |                  | packets. Output packets are non-jumbo packets.                                        |
84    |   |                  |                                                                                       |
85    +---+------------------+---------------------------------------------------------------------------------------+
86    | 5 | Traffic manager  | Traffic manager attached to a specific NIC output port, performing congestion         |
87    |   |                  | management and hierarchical scheduling according to pre-defined SLAs.                 |
88    |   |                  |                                                                                       |
89    +---+------------------+---------------------------------------------------------------------------------------+
90    | 6 | KNI              | Send/receive packets to/from Linux kernel space.                                      |
91    |   |                  |                                                                                       |
92    +---+------------------+---------------------------------------------------------------------------------------+
93    | 7 | Source           | Input port used as packet generator. Similar to Linux kernel /dev/zero character      |
94    |   |                  | device.                                                                               |
95    |   |                  |                                                                                       |
96    +---+------------------+---------------------------------------------------------------------------------------+
97    | 8 | Sink             | Output port used to drop all input packets. Similar to Linux kernel /dev/null         |
98    |   |                  | character device.                                                                     |
99    |   |                  |                                                                                       |
100    +---+------------------+---------------------------------------------------------------------------------------+
101    | 9 | Sym_crypto       | Output port used to extract DPDK Cryptodev operations from a fixed offset of the      |
102    |   |                  | packet and then enqueue to the Cryptodev PMD. Input port used to dequeue the          |
103    |   |                  | Cryptodev operations from the Cryptodev PMD and then retrieve the packets from them.  |
104    +---+------------------+---------------------------------------------------------------------------------------+
105
106 Port Interface
107 ~~~~~~~~~~~~~~
108
109 Each port is unidirectional, i.e. either input port or output port.
110 Each input/output port is required to implement an abstract interface that
111 defines the initialization and run-time operation of the port.
112 The port abstract interface is described in.
113
114 .. _table_qos_20:
115
116 .. table:: 20 Port Abstract Interface
117
118    +---+----------------+-----------------------------------------------------------------------------------------+
119    | # | Port Operation | Description                                                                             |
120    |   |                |                                                                                         |
121    +===+================+=========================================================================================+
122    | 1 | Create         | Create the low-level port object (e.g. queue). Can internally allocate memory.          |
123    |   |                |                                                                                         |
124    +---+----------------+-----------------------------------------------------------------------------------------+
125    | 2 | Free           | Free the resources (e.g. memory) used by the low-level port object.                     |
126    |   |                |                                                                                         |
127    +---+----------------+-----------------------------------------------------------------------------------------+
128    | 3 | RX             | Read a burst of input packets. Non-blocking operation. Only defined for input ports.    |
129    |   |                |                                                                                         |
130    +---+----------------+-----------------------------------------------------------------------------------------+
131    | 4 | TX             | Write a burst of input packets. Non-blocking operation. Only defined for output ports.  |
132    |   |                |                                                                                         |
133    +---+----------------+-----------------------------------------------------------------------------------------+
134    | 5 | Flush          | Flush the output buffer. Only defined for output ports.                                 |
135    |   |                |                                                                                         |
136    +---+----------------+-----------------------------------------------------------------------------------------+
137
138 Table Library Design
139 --------------------
140
141 Table Types
142 ~~~~~~~~~~~
143
144 :numref:`table_qos_21` is a non-exhaustive list of types of tables that can be implemented with the Packet Framework.
145
146 .. _table_qos_21:
147
148 .. table:: Table Types
149
150    +---+----------------------------+-----------------------------------------------------------------------------+
151    | # | Table Type                 | Description                                                                 |
152    |   |                            |                                                                             |
153    +===+============================+=============================================================================+
154    | 1 | Hash table                 | Lookup key is n-tuple based.                                                |
155    |   |                            |                                                                             |
156    |   |                            | Typically, the lookup key is hashed to produce a signature that is used to  |
157    |   |                            | identify a bucket of entries where the lookup key is searched next.         |
158    |   |                            |                                                                             |
159    |   |                            | The signature associated with the lookup key of each input packet is either |
160    |   |                            | read from the packet descriptor (pre-computed signature) or computed at     |
161    |   |                            | table lookup time.                                                          |
162    |   |                            |                                                                             |
163    |   |                            | The table lookup, add entry and delete entry operations, as well as any     |
164    |   |                            | other pipeline block that pre-computes the signature all have to use the    |
165    |   |                            | same hashing algorithm to generate the signature.                           |
166    |   |                            |                                                                             |
167    |   |                            | Typically used to implement flow classification tables, ARP caches, routing |
168    |   |                            | table for tunnelling protocols, etc.                                        |
169    |   |                            |                                                                             |
170    +---+----------------------------+-----------------------------------------------------------------------------+
171    | 2 | Longest Prefix Match (LPM) | Lookup key is the IP address.                                               |
172    |   |                            |                                                                             |
173    |   |                            | Each table entries has an associated IP prefix (IP and depth).              |
174    |   |                            |                                                                             |
175    |   |                            | The table lookup operation selects the IP prefix that is matched by the     |
176    |   |                            | lookup key; in case of multiple matches, the entry with the longest prefix  |
177    |   |                            | depth wins.                                                                 |
178    |   |                            |                                                                             |
179    |   |                            | Typically used to implement IP routing tables.                              |
180    |   |                            |                                                                             |
181    +---+----------------------------+-----------------------------------------------------------------------------+
182    | 3 | Access Control List (ACLs) | Lookup key is 7-tuple of two VLAN/MPLS labels, IP destination address,      |
183    |   |                            | IP source addresses, L4 protocol, L4 destination port, L4 source port.      |
184    |   |                            |                                                                             |
185    |   |                            | Each table entry has an associated ACL and priority. The ACL contains bit   |
186    |   |                            | masks for the VLAN/MPLS labels, IP prefix for IP destination address, IP    |
187    |   |                            | prefix for IP source addresses, L4 protocol and bitmask, L4 destination     |
188    |   |                            | port and bit mask, L4 source port and bit mask.                             |
189    |   |                            |                                                                             |
190    |   |                            | The table lookup operation selects the ACL that is matched by the lookup    |
191    |   |                            | key; in case of multiple matches, the entry with the highest priority wins. |
192    |   |                            |                                                                             |
193    |   |                            | Typically used to implement rule databases for firewalls, etc.              |
194    |   |                            |                                                                             |
195    +---+----------------------------+-----------------------------------------------------------------------------+
196    | 4 | Pattern matching search    | Lookup key is the packet payload.                                           |
197    |   |                            |                                                                             |
198    |   |                            | Table is a database of patterns, with each pattern having a priority        |
199    |   |                            | assigned.                                                                   |
200    |   |                            |                                                                             |
201    |   |                            | The table lookup operation selects the patterns that is matched by the      |
202    |   |                            | input packet; in case of multiple matches, the matching pattern with the    |
203    |   |                            | highest priority wins.                                                      |
204    |   |                            |                                                                             |
205    +---+----------------------------+-----------------------------------------------------------------------------+
206    | 5 | Array                      | Lookup key is the table entry index itself.                                 |
207    |   |                            |                                                                             |
208    +---+----------------------------+-----------------------------------------------------------------------------+
209
210 Table Interface
211 ~~~~~~~~~~~~~~~
212
213 Each table is required to implement an abstract interface that defines the initialization
214 and run-time operation of the table.
215 The table abstract interface is described in :numref:`table_qos_29_1`.
216
217 .. _table_qos_29_1:
218
219 .. table:: Table Abstract Interface
220
221    +---+-----------------+----------------------------------------------------------------------------------------+
222    | # | Table operation | Description                                                                            |
223    |   |                 |                                                                                        |
224    +===+=================+========================================================================================+
225    | 1 | Create          | Create the low-level data structures of the lookup table. Can internally allocate      |
226    |   |                 | memory.                                                                                |
227    |   |                 |                                                                                        |
228    +---+-----------------+----------------------------------------------------------------------------------------+
229    | 2 | Free            | Free up all the resources used by the lookup table.                                    |
230    |   |                 |                                                                                        |
231    +---+-----------------+----------------------------------------------------------------------------------------+
232    | 3 | Add entry       | Add new entry to the lookup table.                                                     |
233    |   |                 |                                                                                        |
234    +---+-----------------+----------------------------------------------------------------------------------------+
235    | 4 | Delete entry    | Delete specific entry from the lookup table.                                           |
236    |   |                 |                                                                                        |
237    +---+-----------------+----------------------------------------------------------------------------------------+
238    | 5 | Lookup          | Look up a burst of input packets and return a bit mask specifying the result of the    |
239    |   |                 | lookup operation for each packet: a set bit signifies lookup hit for the corresponding |
240    |   |                 | packet, while a cleared bit a lookup miss.                                             |
241    |   |                 |                                                                                        |
242    |   |                 | For each lookup hit packet, the lookup operation also returns a pointer to the table   |
243    |   |                 | entry that was hit, which contains the actions to be applied on the packet and any     |
244    |   |                 | associated metadata.                                                                   |
245    |   |                 |                                                                                        |
246    |   |                 | For each lookup miss packet, the actions to be applied on the packet and any           |
247    |   |                 | associated metadata are specified by the default table entry preconfigured for lookup  |
248    |   |                 | miss.                                                                                  |
249    |   |                 |                                                                                        |
250    +---+-----------------+----------------------------------------------------------------------------------------+
251
252
253 Hash Table Design
254 ~~~~~~~~~~~~~~~~~
255
256 Hash Table Overview
257 ^^^^^^^^^^^^^^^^^^^
258
259 Hash tables are important because the key lookup operation is optimized for speed:
260 instead of having to linearly search the lookup key through all the keys in the table,
261 the search is limited to only the keys stored in a single table bucket.
262
263 **Associative Arrays**
264
265 An associative array is a function that can be specified as a set of (key, value) pairs,
266 with each key from the possible set of input keys present at most once.
267 For a given associative array, the possible operations are:
268
269 #.  *add (key, value)*: When no value is currently associated with *key*, then the (key, *value* ) association is created.
270     When *key* is already associated value *value0*, then the association (*key*, *value0*) is removed
271     and association *(key, value)* is created;
272
273 #.  *delete key*: When no value is currently associated with *key*, this operation has no effect.
274     When *key* is already associated  *value*, then association  *(key, value)* is removed;
275
276 #.  *lookup key*: When no value is currently associated with  *key*, then this operation returns void value (lookup miss).
277     When *key* is associated with *value*, then this operation returns *value*.
278     The *(key, value)* association is not changed.
279
280 The matching criterion used to compare the input key against the keys in the associative array is *exact match*,
281 as the key size (number of bytes) and the key value (array of bytes) have to match exactly for the two keys under comparison.
282
283 **Hash Function**
284
285 A hash function deterministically maps data of variable length (key) to data of fixed size (hash value or key signature).
286 Typically, the size of the key is bigger than the size of the key signature.
287 The hash function basically compresses a long key into a short signature.
288 Several keys can share the same signature (collisions).
289
290 High quality hash functions have uniform distribution.
291 For large number of keys, when dividing the space of signature values into a fixed number of equal intervals (buckets),
292 it is desirable to have the key signatures evenly distributed across these intervals (uniform distribution),
293 as opposed to most of the signatures going into only a few of the intervals
294 and the rest of the intervals being largely unused (non-uniform distribution).
295
296 **Hash Table**
297
298 A hash table is an associative array that uses a hash function for its operation.
299 The reason for using a hash function is to optimize the performance of the lookup operation
300 by minimizing the number of table keys that have to be compared against the input key.
301
302 Instead of storing the (key, value) pairs in a single list, the hash table maintains multiple lists (buckets).
303 For any given key, there is a single bucket where that key might exist, and this bucket is uniquely identified based on the key signature.
304 Once the key signature is computed and the hash table bucket identified,
305 the key is either located in this bucket or it is not present in the hash table at all,
306 so the key search can be narrowed down from the full set of keys currently in the table
307 to just the set of keys currently in the identified table bucket.
308
309 The performance of the hash table lookup operation is greatly improved,
310 provided that the table keys are evenly distributed among the hash table buckets,
311 which can be achieved by using a hash function with uniform distribution.
312 The rule to map a key to its bucket can simply be to use the key signature (modulo the number of table buckets) as the table bucket ID:
313
314     *bucket_id = f_hash(key) % n_buckets;*
315
316 By selecting the number of buckets to be a power of two, the modulo operator can be replaced by a bitwise AND logical operation:
317
318     *bucket_id = f_hash(key) & (n_buckets - 1);*
319
320 considering *n_bits* as the number of bits set in *bucket_mask = n_buckets - 1*,
321 this means that all the keys that end up in the same hash table bucket have the lower *n_bits* of their signature identical.
322 In order to reduce the number of keys in the same bucket (collisions), the number of hash table buckets needs to be increased.
323
324 In packet processing context, the sequence of operations involved in hash table operations is described in :numref:`figure_figure33`:
325
326 .. _figure_figure33:
327
328 .. figure:: img/figure33.*
329
330    Sequence of Steps for Hash Table Operations in a Packet Processing Context
331
332
333
334 Hash Table Use Cases
335 ^^^^^^^^^^^^^^^^^^^^
336
337 **Flow Classification**
338
339 *Description:* The flow classification is executed at least once for each input packet.
340 This operation maps each incoming packet against one of the known traffic flows in the flow database that typically contains millions of flows.
341
342 *Hash table name:* Flow classification table
343
344 *Number of keys:* Millions
345
346 *Key format:* n-tuple of packet fields that uniquely identify a traffic flow/connection.
347 Example: DiffServ 5-tuple of (Source IP address, Destination IP address, L4 protocol, L4 protocol source port, L4 protocol destination port).
348 For IPv4 protocol and L4 protocols like TCP, UDP or SCTP, the size of the DiffServ 5-tuple is 13 bytes, while for IPv6 it is 37 bytes.
349
350 *Key value (key data):* actions and action meta-data describing what processing to be applied for the packets of the current flow.
351 The size of the data associated with each traffic flow can vary from 8 bytes to kilobytes.
352
353 **Address Resolution Protocol (ARP)**
354
355 *Description:* Once a route has been identified for an IP packet (so the output interface and the IP address of the next hop station are known),
356 the MAC address of the next hop station is needed in order to send this packet onto the next leg of the journey
357 towards its destination (as identified by its destination IP address).
358 The MAC address of the next hop station becomes the destination MAC address of the outgoing Ethernet frame.
359
360 *Hash table name:* ARP table
361
362 *Number of keys:* Thousands
363
364 *Key format:* The pair of (Output interface, Next Hop IP address), which is typically 5 bytes for IPv4 and 17 bytes for IPv6.
365
366 *Key value (key data):* MAC address of the next hop station (6 bytes).
367
368 Hash Table Types
369 ^^^^^^^^^^^^^^^^
370
371 :numref:`table_qos_22` lists the hash table configuration parameters shared by all different hash table types.
372
373 .. _table_qos_22:
374
375 .. table:: Configuration Parameters Common for All Hash Table Types
376
377    +---+---------------------------+------------------------------------------------------------------------------+
378    | # | Parameter                 | Details                                                                      |
379    |   |                           |                                                                              |
380    +===+===========================+==============================================================================+
381    | 1 | Key size                  | Measured as number of bytes. All keys have the same size.                    |
382    |   |                           |                                                                              |
383    +---+---------------------------+------------------------------------------------------------------------------+
384    | 2 | Key value (key data) size | Measured as number of bytes.                                                 |
385    |   |                           |                                                                              |
386    +---+---------------------------+------------------------------------------------------------------------------+
387    | 3 | Number of buckets         | Needs to be a power of two.                                                  |
388    |   |                           |                                                                              |
389    +---+---------------------------+------------------------------------------------------------------------------+
390    | 4 | Maximum number of keys    | Needs to be a power of two.                                                  |
391    |   |                           |                                                                              |
392    +---+---------------------------+------------------------------------------------------------------------------+
393    | 5 | Hash function             | Examples: jhash, CRC hash, etc.                                              |
394    |   |                           |                                                                              |
395    +---+---------------------------+------------------------------------------------------------------------------+
396    | 6 | Hash function seed        | Parameter to be passed to the hash function.                                 |
397    |   |                           |                                                                              |
398    +---+---------------------------+------------------------------------------------------------------------------+
399    | 7 | Key offset                | Offset of the lookup key byte array within the packet meta-data stored in    |
400    |   |                           | the packet buffer.                                                           |
401    |   |                           |                                                                              |
402    +---+---------------------------+------------------------------------------------------------------------------+
403
404 Bucket Full Problem
405 """""""""""""""""""
406
407 On initialization, each hash table bucket is allocated space for exactly 4 keys.
408 As keys are added to the table, it can happen that a given bucket already has 4 keys when a new key has to be added to this bucket.
409 The possible options are:
410
411 #.  **Least Recently Used (LRU) Hash Table.**
412     One of the existing keys in the bucket is deleted and the new key is added in its place.
413     The number of keys in each bucket never grows bigger than 4. The logic to pick the key to be dropped from the bucket is LRU.
414     The hash table lookup operation maintains the order in which the keys in the same bucket are hit, so every time a key is hit,
415     it becomes the new Most Recently Used (MRU) key, i.e. the last candidate for drop.
416     When a key is added to the bucket, it also becomes the new MRU key.
417     When a key needs to be picked and dropped, the first candidate for drop, i.e. the current LRU key, is always picked.
418     The LRU logic requires maintaining specific data structures per each bucket.
419
420 #.  **Extendable Bucket Hash Table.**
421     The bucket is extended with space for 4 more keys.
422     This is done by allocating additional memory at table initialization time,
423     which is used to create a pool of free keys (the size of this pool is configurable and always a multiple of 4).
424     On key add operation, the allocation of a group of 4 keys only happens successfully within the limit of free keys,
425     otherwise the key add operation fails.
426     On key delete operation, a group of 4 keys is freed back to the pool of free keys
427     when the key to be deleted is the only key that was used within its group of 4 keys at that time.
428     On key lookup operation, if the current bucket is in extended state and a match is not found in the first group of 4 keys,
429     the search continues beyond the first group of 4 keys, potentially until all keys in this bucket are examined.
430     The extendable bucket logic requires maintaining specific data structures per table and per each bucket.
431
432 .. _table_qos_23:
433
434 .. table:: Configuration Parameters Specific to Extendable Bucket Hash Table
435
436    +---+---------------------------+--------------------------------------------------+
437    | # | Parameter                 | Details                                          |
438    |   |                           |                                                  |
439    +===+===========================+==================================================+
440    | 1 | Number of additional keys | Needs to be a power of two, at least equal to 4. |
441    |   |                           |                                                  |
442    +---+---------------------------+--------------------------------------------------+
443
444
445 Signature Computation
446 """""""""""""""""""""
447
448 The possible options for key signature computation are:
449
450 #.  **Pre-computed key signature.**
451     The key lookup operation is split between two CPU cores.
452     The first CPU core (typically the CPU core that performs packet RX) extracts the key from the input packet,
453     computes the key signature and saves both the key and the key signature in the packet buffer as packet meta-data.
454     The second CPU core reads both the key and the key signature from the packet meta-data
455     and performs the bucket search step of the key lookup operation.
456
457 #.  **Key signature computed on lookup ("do-sig" version).**
458     The same CPU core reads the key from the packet meta-data, uses it to compute the key signature
459     and also performs the bucket search step of the key lookup operation.
460
461 .. _table_qos_24:
462
463 .. table:: Configuration Parameters Specific to Pre-computed Key Signature Hash Table
464
465    +---+------------------+-----------------------------------------------------------------------+
466    | # | Parameter        | Details                                                               |
467    |   |                  |                                                                       |
468    +===+==================+=======================================================================+
469    | 1 | Signature offset | Offset of the pre-computed key signature within the packet meta-data. |
470    |   |                  |                                                                       |
471    +---+------------------+-----------------------------------------------------------------------+
472
473 Key Size Optimized Hash Tables
474 """"""""""""""""""""""""""""""
475
476 For specific key sizes, the data structures and algorithm of key lookup operation can be specially handcrafted for further performance improvements,
477 so following options are possible:
478
479 #.  **Implementation supporting configurable key size.**
480
481 #.  **Implementation supporting a single key size.**
482     Typical key sizes are 8 bytes and 16 bytes.
483
484 Bucket Search Logic for Configurable Key Size Hash Tables
485 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
486
487 The performance of the bucket search logic is one of the main factors influencing the performance of the key lookup operation.
488 The data structures and algorithm are designed to make the best use of Intel CPU architecture resources like:
489 cache memory space, cache memory bandwidth, external memory bandwidth, multiple execution units working in parallel,
490 out of order instruction execution, special CPU instructions, etc.
491
492 The bucket search logic handles multiple input packets in parallel.
493 It is built as a pipeline of several stages (3 or 4), with each pipeline stage handling two different packets from the burst of input packets.
494 On each pipeline iteration, the packets are pushed to the next pipeline stage: for the 4-stage pipeline,
495 two packets (that just completed stage 3) exit the pipeline,
496 two packets (that just completed stage 2) are now executing stage 3, two packets (that just completed stage 1) are now executing stage 2,
497 two packets (that just completed stage 0) are now executing stage 1 and two packets (next two packets to read from the burst of input packets)
498 are entering the pipeline to execute stage 0.
499 The pipeline iterations continue until all packets from the burst of input packets execute the last stage of the pipeline.
500
501 The bucket search logic is broken into pipeline stages at the boundary of the next memory access.
502 Each pipeline stage uses data structures that are stored (with high probability) into the L1 or L2 cache memory of the current CPU core and
503 breaks just before the next memory access required by the algorithm.
504 The current pipeline stage finalizes by prefetching the data structures required by the next pipeline stage,
505 so given enough time for the prefetch to complete,
506 when the next pipeline stage eventually gets executed for the same packets,
507 it will read the data structures it needs from L1 or L2 cache memory and thus avoid the significant penalty incurred by L2 or L3 cache memory miss.
508
509 By prefetching the data structures required by the next pipeline stage in advance (before they are used)
510 and switching to executing another pipeline stage for different packets,
511 the number of L2 or L3 cache memory misses is greatly reduced, hence one of the main reasons for improved performance.
512 This is because the cost of L2/L3 cache memory miss on memory read accesses is high, as usually due to data dependency between instructions,
513 the CPU execution units have to stall until the read operation is completed from L3 cache memory or external DRAM memory.
514 By using prefetch instructions, the latency of memory read accesses is hidden,
515 provided that it is preformed early enough before the respective data structure is actually used.
516
517 By splitting the processing into several stages that are executed on different packets (the packets from the input burst are interlaced),
518 enough work is created to allow the prefetch instructions to complete successfully (before the prefetched data structures are actually accessed) and
519 also the data dependency between instructions is loosened.
520 For example, for the 4-stage pipeline, stage 0 is executed on packets 0 and 1 and then,
521 before same packets 0 and 1 are used (i.e. before stage 1 is executed on packets 0 and 1),
522 different packets are used: packets 2 and 3 (executing stage 1), packets 4 and 5 (executing stage 2) and packets 6 and 7 (executing stage 3).
523 By executing useful work while the data structures are brought into the L1 or L2 cache memory, the latency of the read memory accesses is hidden.
524 By increasing the gap between two consecutive accesses to the same data structure, the data dependency between instructions is loosened;
525 this allows making the best use of the super-scalar and out-of-order execution CPU architecture,
526 as the number of CPU core execution units that are active (rather than idle or stalled due to data dependency constraints between instructions) is maximized.
527
528 The bucket search logic is also implemented without using any branch instructions.
529 This avoids the important cost associated with flushing the CPU core execution pipeline on every instance of branch misprediction.
530
531 Configurable Key Size Hash Table
532 """"""""""""""""""""""""""""""""
533
534 :numref:`figure_figure34`, :numref:`table_qos_25` and :numref:`table_qos_26` detail the main data structures used to implement configurable key size hash tables (either LRU or extendable bucket,
535 either with pre-computed signature or "do-sig").
536
537 .. _figure_figure34:
538
539 .. figure:: img/figure34.*
540
541    Data Structures for Configurable Key Size Hash Tables
542
543
544 .. _table_qos_25:
545
546 .. table:: Main Large Data Structures (Arrays) used for Configurable Key Size Hash Tables
547
548    +---+-------------------------+------------------------------+---------------------------+-------------------------------+
549    | # | Array name              | Number of entries            | Entry size (bytes)        | Description                   |
550    |   |                         |                              |                           |                               |
551    +===+=========================+==============================+===========================+===============================+
552    | 1 | Bucket array            | n_buckets (configurable)     | 32                        | Buckets of the hash table.    |
553    |   |                         |                              |                           |                               |
554    +---+-------------------------+------------------------------+---------------------------+-------------------------------+
555    | 2 | Bucket extensions array | n_buckets_ext (configurable) | 32                        | This array is only created    |
556    |   |                         |                              |                           | for extendable bucket tables. |
557    |   |                         |                              |                           |                               |
558    +---+-------------------------+------------------------------+---------------------------+-------------------------------+
559    | 3 | Key array               | n_keys                       | key_size (configurable)   | Keys added to the hash table. |
560    |   |                         |                              |                           |                               |
561    +---+-------------------------+------------------------------+---------------------------+-------------------------------+
562    | 4 | Data array              | n_keys                       | entry_size (configurable) | Key values (key data)         |
563    |   |                         |                              |                           | associated with the hash      |
564    |   |                         |                              |                           | table keys.                   |
565    |   |                         |                              |                           |                               |
566    +---+-------------------------+------------------------------+---------------------------+-------------------------------+
567
568 .. _table_qos_26:
569
570 .. table:: Field Description for Bucket Array Entry (Configurable Key Size Hash Tables)
571
572    +---+------------------+--------------------+------------------------------------------------------------------+
573    | # | Field name       | Field size (bytes) | Description                                                      |
574    |   |                  |                    |                                                                  |
575    +===+==================+====================+==================================================================+
576    | 1 | Next Ptr/LRU     | 8                  | For LRU tables, this fields represents the LRU list for the      |
577    |   |                  |                    | current bucket stored as array of 4 entries of 2 bytes each.     |
578    |   |                  |                    | Entry 0 stores the index (0 .. 3) of the MRU key, while entry 3  |
579    |   |                  |                    | stores the index of the LRU key.                                 |
580    |   |                  |                    |                                                                  |
581    |   |                  |                    | For extendable bucket tables, this field represents the next     |
582    |   |                  |                    | pointer (i.e. the pointer to the next group of 4 keys linked to  |
583    |   |                  |                    | the current bucket). The next pointer is not NULL if the bucket  |
584    |   |                  |                    | is currently extended or NULL otherwise.                         |
585    |   |                  |                    | To help the branchless implementation, bit 0 (least significant  |
586    |   |                  |                    | bit) of this field is set to 1 if the next pointer is not NULL   |
587    |   |                  |                    | and to 0 otherwise.                                              |
588    |   |                  |                    |                                                                  |
589    +---+------------------+--------------------+------------------------------------------------------------------+
590    | 2 | Sig[0 .. 3]      | 4 x 2              | If key X (X = 0 .. 3) is valid, then sig X bits 15 .. 1 store    |
591    |   |                  |                    | the most significant 15 bits of key X signature and sig X bit 0  |
592    |   |                  |                    | is set to 1.                                                     |
593    |   |                  |                    |                                                                  |
594    |   |                  |                    | If key X is not valid, then sig X is set to zero.                |
595    |   |                  |                    |                                                                  |
596    +---+------------------+--------------------+------------------------------------------------------------------+
597    | 3 | Key Pos [0 .. 3] | 4 x 4              | If key X is valid (X = 0 .. 3), then Key Pos X represents the    |
598    |   |                  |                    | index into the key array where key X is stored, as well as the   |
599    |   |                  |                    | index into the data array where the value associated with key X  |
600    |   |                  |                    | is stored.                                                       |
601    |   |                  |                    |                                                                  |
602    |   |                  |                    | If key X is not valid, then the value of Key Pos X is undefined. |
603    |   |                  |                    |                                                                  |
604    +---+------------------+--------------------+------------------------------------------------------------------+
605
606
607 :numref:`figure_figure35` and :numref:`table_qos_27` detail the bucket search pipeline stages (either LRU or extendable bucket,
608 either with pre-computed signature or "do-sig").
609 For each pipeline stage, the described operations are applied to each of the two packets handled by that stage.
610
611 .. _figure_figure35:
612
613 .. figure:: img/figure35.*
614
615    Bucket Search Pipeline for Key Lookup Operation (Configurable Key Size Hash
616    Tables)
617
618
619 .. _table_qos_27:
620
621 .. table:: Description of the Bucket Search Pipeline Stages (Configurable Key Size Hash Tables)
622
623    +---+---------------------------+------------------------------------------------------------------------------+
624    | # | Stage name                | Description                                                                  |
625    |   |                           |                                                                              |
626    +===+===========================+==============================================================================+
627    | 0 | Prefetch packet meta-data | Select next two packets from the burst of input packets.                     |
628    |   |                           |                                                                              |
629    |   |                           | Prefetch packet meta-data containing the key and key signature.              |
630    |   |                           |                                                                              |
631    +---+---------------------------+------------------------------------------------------------------------------+
632    | 1 | Prefetch table bucket     | Read the key signature from the packet meta-data (for extendable bucket hash |
633    |   |                           | tables) or read the key from the packet meta-data and compute key signature  |
634    |   |                           | (for LRU tables).                                                            |
635    |   |                           |                                                                              |
636    |   |                           | Identify the bucket ID using the key signature.                              |
637    |   |                           |                                                                              |
638    |   |                           | Set bit 0 of the signature to 1 (to match only signatures of valid keys from |
639    |   |                           | the table).                                                                  |
640    |   |                           |                                                                              |
641    |   |                           | Prefetch the bucket.                                                         |
642    |   |                           |                                                                              |
643    +---+---------------------------+------------------------------------------------------------------------------+
644    | 2 | Prefetch table key        | Read the key signatures from the bucket.                                     |
645    |   |                           |                                                                              |
646    |   |                           | Compare the signature of the input key against the 4 key signatures from the |
647    |   |                           | packet. As result, the following is obtained:                                |
648    |   |                           |                                                                              |
649    |   |                           | *match*                                                                      |
650    |   |                           | = equal to TRUE if there was at least one signature match and to FALSE in    |
651    |   |                           | the case of no signature match;                                              |
652    |   |                           |                                                                              |
653    |   |                           | *match_many*                                                                 |
654    |   |                           | = equal to TRUE is there were more than one signature matches (can be up to  |
655    |   |                           | 4 signature matches in the worst case scenario) and to FALSE otherwise;      |
656    |   |                           |                                                                              |
657    |   |                           | *match_pos*                                                                  |
658    |   |                           | = the index of the first key that produced signature match (only valid if    |
659    |   |                           | match is true).                                                              |
660    |   |                           |                                                                              |
661    |   |                           | For extendable bucket hash tables only, set                                  |
662    |   |                           | *match_many*                                                                 |
663    |   |                           | to TRUE if next pointer is valid.                                            |
664    |   |                           |                                                                              |
665    |   |                           | Prefetch the bucket key indicated by                                         |
666    |   |                           | *match_pos*                                                                  |
667    |   |                           | (even if                                                                     |
668    |   |                           | *match_pos*                                                                  |
669    |   |                           | does not point to valid key valid).                                          |
670    |   |                           |                                                                              |
671    +---+---------------------------+------------------------------------------------------------------------------+
672    | 3 | Prefetch table data       | Read the bucket key indicated by                                             |
673    |   |                           | *match_pos*.                                                                 |
674    |   |                           |                                                                              |
675    |   |                           | Compare the bucket key against the input key. As result, the following is    |
676    |   |                           | obtained:                                                                    |
677    |   |                           | *match_key*                                                                  |
678    |   |                           | = equal to TRUE if the two keys match and to FALSE otherwise.                |
679    |   |                           |                                                                              |
680    |   |                           | Report input key as lookup hit only when both                                |
681    |   |                           | *match*                                                                      |
682    |   |                           | and                                                                          |
683    |   |                           | *match_key*                                                                  |
684    |   |                           | are equal to TRUE and as lookup miss otherwise.                              |
685    |   |                           |                                                                              |
686    |   |                           | For LRU tables only, use branchless logic to update the bucket LRU list      |
687    |   |                           | (the current key becomes the new MRU) only on lookup hit.                    |
688    |   |                           |                                                                              |
689    |   |                           | Prefetch the key value (key data) associated with the current key (to avoid  |
690    |   |                           | branches, this is done on both lookup hit and miss).                         |
691    |   |                           |                                                                              |
692    +---+---------------------------+------------------------------------------------------------------------------+
693
694
695 Additional notes:
696
697 #.  The pipelined version of the bucket search algorithm is executed only if there are at least 7 packets in the burst of input packets.
698     If there are less than 7 packets in the burst of input packets,
699     a non-optimized implementation of the bucket search algorithm is executed.
700
701 #.  Once the pipelined version of the bucket search algorithm has been executed for all the packets in the burst of input packets,
702     the non-optimized implementation of the bucket search algorithm is also executed for any packets that did not produce a lookup hit,
703     but have the *match_many* flag set.
704     As result of executing the non-optimized version, some of these packets may produce a lookup hit or lookup miss.
705     This does not impact the performance of the key lookup operation,
706     as the probability of matching more than one signature in the same group of 4 keys or of having the bucket in extended state
707     (for extendable bucket hash tables only) is relatively small.
708
709 **Key Signature Comparison Logic**
710
711 The key signature comparison logic is described in :numref:`table_qos_28`.
712
713 .. _table_qos_28:
714
715 .. table:: Lookup Tables for Match, Match_Many and Match_Pos
716
717    +----+------+---------------+--------------------+--------------------+
718    | #  | mask | match (1 bit) | match_many (1 bit) | match_pos (2 bits) |
719    |    |      |               |                    |                    |
720    +----+------+---------------+--------------------+--------------------+
721    | 0  | 0000 | 0             | 0                  | 00                 |
722    |    |      |               |                    |                    |
723    +----+------+---------------+--------------------+--------------------+
724    | 1  | 0001 | 1             | 0                  | 00                 |
725    |    |      |               |                    |                    |
726    +----+------+---------------+--------------------+--------------------+
727    | 2  | 0010 | 1             | 0                  | 01                 |
728    |    |      |               |                    |                    |
729    +----+------+---------------+--------------------+--------------------+
730    | 3  | 0011 | 1             | 1                  | 00                 |
731    |    |      |               |                    |                    |
732    +----+------+---------------+--------------------+--------------------+
733    | 4  | 0100 | 1             | 0                  | 10                 |
734    |    |      |               |                    |                    |
735    +----+------+---------------+--------------------+--------------------+
736    | 5  | 0101 | 1             | 1                  | 00                 |
737    |    |      |               |                    |                    |
738    +----+------+---------------+--------------------+--------------------+
739    | 6  | 0110 | 1             | 1                  | 01                 |
740    |    |      |               |                    |                    |
741    +----+------+---------------+--------------------+--------------------+
742    | 7  | 0111 | 1             | 1                  | 00                 |
743    |    |      |               |                    |                    |
744    +----+------+---------------+--------------------+--------------------+
745    | 8  | 1000 | 1             | 0                  | 11                 |
746    |    |      |               |                    |                    |
747    +----+------+---------------+--------------------+--------------------+
748    | 9  | 1001 | 1             | 1                  | 00                 |
749    |    |      |               |                    |                    |
750    +----+------+---------------+--------------------+--------------------+
751    | 10 | 1010 | 1             | 1                  | 01                 |
752    |    |      |               |                    |                    |
753    +----+------+---------------+--------------------+--------------------+
754    | 11 | 1011 | 1             | 1                  | 00                 |
755    |    |      |               |                    |                    |
756    +----+------+---------------+--------------------+--------------------+
757    | 12 | 1100 | 1             | 1                  | 10                 |
758    |    |      |               |                    |                    |
759    +----+------+---------------+--------------------+--------------------+
760    | 13 | 1101 | 1             | 1                  | 00                 |
761    |    |      |               |                    |                    |
762    +----+------+---------------+--------------------+--------------------+
763    | 14 | 1110 | 1             | 1                  | 01                 |
764    |    |      |               |                    |                    |
765    +----+------+---------------+--------------------+--------------------+
766    | 15 | 1111 | 1             | 1                  | 00                 |
767    |    |      |               |                    |                    |
768    +----+------+---------------+--------------------+--------------------+
769
770 The input *mask* hash bit X (X = 0 .. 3) set to 1 if input signature is equal to bucket signature X and set to 0 otherwise.
771 The outputs *match*, *match_many* and *match_pos* are 1 bit, 1 bit and 2 bits in size respectively and their meaning has been explained above.
772
773 As displayed in :numref:`table_qos_29`, the lookup tables for *match* and *match_many* can be collapsed into a single 32-bit value and the lookup table for
774 *match_pos* can be collapsed into a 64-bit value.
775 Given the input *mask*, the values for *match*, *match_many* and *match_pos* can be obtained by indexing their respective bit array to extract 1 bit,
776 1 bit and 2 bits respectively with branchless logic.
777
778 .. _table_qos_29:
779
780 .. table:: Collapsed Lookup Tables for Match, Match_Many and Match_Pos
781
782    +------------+------------------------------------------+-------------------+
783    |            | Bit array                                | Hexadecimal value |
784    |            |                                          |                   |
785    +------------+------------------------------------------+-------------------+
786    | match      | 1111_1111_1111_1110                      | 0xFFFELLU         |
787    |            |                                          |                   |
788    +------------+------------------------------------------+-------------------+
789    | match_many | 1111_1110_1110_1000                      | 0xFEE8LLU         |
790    |            |                                          |                   |
791    +------------+------------------------------------------+-------------------+
792    | match_pos  | 0001_0010_0001_0011__0001_0010_0001_0000 | 0x12131210LLU     |
793    |            |                                          |                   |
794    +------------+------------------------------------------+-------------------+
795
796
797 The pseudo-code for match, match_many and match_pos is::
798
799     match = (0xFFFELLU >> mask) & 1;
800
801     match_many = (0xFEE8LLU >> mask) & 1;
802
803     match_pos = (0x12131210LLU >> (mask << 1)) & 3;
804
805 Single Key Size Hash Tables
806 """""""""""""""""""""""""""
807
808 :numref:`figure_figure37`, :numref:`figure_figure38`, :numref:`table_qos_30` and :numref:`table_qos_31` detail the main data structures used to implement 8-byte and 16-byte key hash tables
809 (either LRU or extendable bucket, either with pre-computed signature or "do-sig").
810
811 .. _figure_figure37:
812
813 .. figure:: img/figure37.*
814
815    Data Structures for 8-byte Key Hash Tables
816
817
818 .. _figure_figure38:
819
820 .. figure:: img/figure38.*
821
822    Data Structures for 16-byte Key Hash Tables
823
824
825 .. _table_qos_30:
826
827 .. table:: Main Large Data Structures (Arrays) used for 8-byte and 16-byte Key Size Hash Tables
828
829    +---+-------------------------+------------------------------+----------------------+------------------------------------+
830    | # | Array name              | Number of entries            | Entry size (bytes)   | Description                        |
831    |   |                         |                              |                      |                                    |
832    +===+=========================+==============================+======================+====================================+
833    | 1 | Bucket array            | n_buckets (configurable)     | *8-byte key size:*   | Buckets of the hash table.         |
834    |   |                         |                              |                      |                                    |
835    |   |                         |                              | 64 + 4 x entry_size  |                                    |
836    |   |                         |                              |                      |                                    |
837    |   |                         |                              |                      |                                    |
838    |   |                         |                              | *16-byte key size:*  |                                    |
839    |   |                         |                              |                      |                                    |
840    |   |                         |                              | 128 + 4 x entry_size |                                    |
841    |   |                         |                              |                      |                                    |
842    +---+-------------------------+------------------------------+----------------------+------------------------------------+
843    | 2 | Bucket extensions array | n_buckets_ext (configurable) | *8-byte key size:*   | This array is only created for     |
844    |   |                         |                              |                      | extendable bucket tables.          |
845    |   |                         |                              |                      |                                    |
846    |   |                         |                              | 64 + 4 x entry_size  |                                    |
847    |   |                         |                              |                      |                                    |
848    |   |                         |                              |                      |                                    |
849    |   |                         |                              | *16-byte key size:*  |                                    |
850    |   |                         |                              |                      |                                    |
851    |   |                         |                              | 128 + 4 x entry_size |                                    |
852    |   |                         |                              |                      |                                    |
853    +---+-------------------------+------------------------------+----------------------+------------------------------------+
854
855 .. _table_qos_31:
856
857 .. table:: Field Description for Bucket Array Entry (8-byte and 16-byte Key Hash Tables)
858
859    +---+---------------+--------------------+-------------------------------------------------------------------------------+
860    | # | Field name    | Field size (bytes) | Description                                                                   |
861    |   |               |                    |                                                                               |
862    +===+===============+====================+===============================================================================+
863    | 1 | Valid         | 8                  | Bit X (X = 0 .. 3) is set to 1 if key X is valid or to 0 otherwise.           |
864    |   |               |                    |                                                                               |
865    |   |               |                    | Bit 4 is only used for extendable bucket tables to help with the              |
866    |   |               |                    | implementation of the branchless logic. In this case, bit 4 is set to 1 if    |
867    |   |               |                    | next pointer is valid (not NULL) or to 0 otherwise.                           |
868    |   |               |                    |                                                                               |
869    +---+---------------+--------------------+-------------------------------------------------------------------------------+
870    | 2 | Next Ptr/LRU  | 8                  | For LRU tables, this fields represents the LRU list for the current bucket    |
871    |   |               |                    | stored as array of 4 entries of 2 bytes each. Entry 0 stores the index        |
872    |   |               |                    | (0 .. 3) of the MRU key, while entry 3 stores the index of the LRU key.       |
873    |   |               |                    |                                                                               |
874    |   |               |                    | For extendable bucket tables, this field represents the next pointer (i.e.    |
875    |   |               |                    | the pointer to the next group of 4 keys linked to the current bucket). The    |
876    |   |               |                    | next pointer is not NULL if the bucket is currently extended or NULL          |
877    |   |               |                    | otherwise.                                                                    |
878    |   |               |                    |                                                                               |
879    +---+---------------+--------------------+-------------------------------------------------------------------------------+
880    | 3 | Key [0 .. 3]  | 4 x key_size       | Full keys.                                                                    |
881    |   |               |                    |                                                                               |
882    +---+---------------+--------------------+-------------------------------------------------------------------------------+
883    | 4 | Data [0 .. 3] | 4 x entry_size     | Full key values (key data) associated with keys 0 .. 3.                       |
884    |   |               |                    |                                                                               |
885    +---+---------------+--------------------+-------------------------------------------------------------------------------+
886
887 and detail the bucket search pipeline used to implement 8-byte and 16-byte key hash tables (either LRU or extendable bucket,
888 either with pre-computed signature or "do-sig").
889 For each pipeline stage, the described operations are applied to each of the two packets handled by that stage.
890
891 .. _figure_figure39:
892
893 .. figure:: img/figure39.*
894
895    Bucket Search Pipeline for Key Lookup Operation (Single Key Size Hash
896    Tables)
897
898
899 .. _table_qos_32:
900
901 .. table:: Description of the Bucket Search Pipeline Stages (8-byte and 16-byte Key Hash Tables)
902
903    +---+---------------------------+-----------------------------------------------------------------------------+
904    | # | Stage name                | Description                                                                 |
905    |   |                           |                                                                             |
906    +===+===========================+=============================================================================+
907    | 0 | Prefetch packet meta-data | #.  Select next two packets from the burst of input packets.                |
908    |   |                           |                                                                             |
909    |   |                           | #.  Prefetch packet meta-data containing the key and key signature.         |
910    |   |                           |                                                                             |
911    +---+---------------------------+-----------------------------------------------------------------------------+
912    | 1 | Prefetch table bucket     | #.  Read the key signature from the packet meta-data (for extendable bucket |
913    |   |                           |     hash tables) or read the key from the packet meta-data and compute key  |
914    |   |                           |     signature (for LRU tables).                                             |
915    |   |                           |                                                                             |
916    |   |                           | #.  Identify the bucket ID using the key signature.                         |
917    |   |                           |                                                                             |
918    |   |                           | #.  Prefetch the bucket.                                                    |
919    |   |                           |                                                                             |
920    +---+---------------------------+-----------------------------------------------------------------------------+
921    | 2 | Prefetch table data       | #.  Read the bucket.                                                        |
922    |   |                           |                                                                             |
923    |   |                           | #.  Compare all 4 bucket keys against the input key.                        |
924    |   |                           |                                                                             |
925    |   |                           | #.  Report input key as lookup hit only when a match is identified (more    |
926    |   |                           |     than one key match is not possible)                                     |
927    |   |                           |                                                                             |
928    |   |                           | #.  For LRU tables only, use branchless logic to update the bucket LRU list |
929    |   |                           |     (the current key becomes the new MRU) only on lookup hit.               |
930    |   |                           |                                                                             |
931    |   |                           | #.  Prefetch the key value (key data) associated with the matched key (to   |
932    |   |                           |     avoid branches, this is done on both lookup hit and miss).              |
933    |   |                           |                                                                             |
934    +---+---------------------------+-----------------------------------------------------------------------------+
935
936 Additional notes:
937
938 #.  The pipelined version of the bucket search algorithm is executed only if there are at least 5 packets in the burst of input packets.
939     If there are less than 5 packets in the burst of input packets, a non-optimized implementation of the bucket search algorithm is executed.
940
941 #.  For extendable bucket hash tables only,
942     once the pipelined version of the bucket search algorithm has been executed for all the packets in the burst of input packets,
943     the non-optimized implementation of the bucket search algorithm is also executed for any packets that did not produce a lookup hit,
944     but have the bucket in extended state.
945     As result of executing the non-optimized version, some of these packets may produce a lookup hit or lookup miss.
946     This does not impact the performance of the key lookup operation,
947     as the probability of having the bucket in extended state is relatively small.
948
949 Pipeline Library Design
950 -----------------------
951
952 A pipeline is defined by:
953
954 #.  The set of input ports;
955
956 #.  The set of output ports;
957
958 #.  The set of tables;
959
960 #.  The set of actions.
961
962 The input ports are connected with the output ports through tree-like topologies of interconnected tables.
963 The table entries contain the actions defining the operations to be executed on the input packets and the packet flow within the pipeline.
964
965 Connectivity of Ports and Tables
966 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
967
968 To avoid any dependencies on the order in which pipeline elements are created,
969 the connectivity of pipeline elements is defined after all the pipeline input ports,
970 output ports and tables have been created.
971
972 General connectivity rules:
973
974 #.  Each input port is connected to a single table. No input port should be left unconnected;
975
976 #.  The table connectivity to other tables or to output ports is regulated by the next hop actions of each table entry and the default table entry.
977     The table connectivity is fluid, as the table entries and the default table entry can be updated during run-time.
978
979     *   A table can have multiple entries (including the default entry) connected to the same output port.
980         A table can have different entries connected to different output ports.
981         Different tables can have entries (including default table entry) connected to the same output port.
982
983     *   A table can have multiple entries (including the default entry) connected to another table,
984         in which case all these entries have to point to the same table.
985         This constraint is enforced by the API and prevents tree-like topologies from being created (allowing table chaining only),
986         with the purpose of simplifying the implementation of the pipeline run-time execution engine.
987
988 Port Actions
989 ~~~~~~~~~~~~
990
991 Port Action Handler
992 ^^^^^^^^^^^^^^^^^^^
993
994 An action handler can be assigned to each input/output port to define actions to be executed on each input packet that is received by the port.
995 Defining the action handler for a specific input/output port is optional (i.e. the action handler can be disabled).
996
997 For input ports, the action handler is executed after RX function. For output ports, the action handler is executed before the TX function.
998
999 The action handler can decide to drop packets.
1000
1001 Table Actions
1002 ~~~~~~~~~~~~~
1003
1004 Table Action Handler
1005 ^^^^^^^^^^^^^^^^^^^^
1006
1007 An action handler to be executed on each input packet can be assigned to each table.
1008 Defining the action handler for a specific table is optional (i.e. the action handler can be disabled).
1009
1010 The action handler is executed after the table lookup operation is performed and the table entry associated with each input packet is identified.
1011 The action handler can only handle the user-defined actions, while the reserved actions (e.g. the next hop actions) are handled by the Packet Framework.
1012 The action handler can decide to drop the input packet.
1013
1014 Reserved Actions
1015 ^^^^^^^^^^^^^^^^
1016
1017 The reserved actions are handled directly by the Packet Framework without the user being able to change their meaning
1018 through the table action handler configuration.
1019 A special category of the reserved actions is represented by the next hop actions, which regulate the packet flow between input ports,
1020 tables and output ports through the pipeline.
1021 :numref:`table_qos_33` lists the next hop actions.
1022
1023 .. _table_qos_33:
1024
1025 .. table:: Next Hop Actions (Reserved)
1026
1027    +---+---------------------+-----------------------------------------------------------------------------------+
1028    | # | Next hop action     | Description                                                                       |
1029    |   |                     |                                                                                   |
1030    +===+=====================+===================================================================================+
1031    | 1 | Drop                | Drop the current packet.                                                          |
1032    |   |                     |                                                                                   |
1033    +---+---------------------+-----------------------------------------------------------------------------------+
1034    | 2 | Send to output port | Send the current packet to specified output port. The output port ID is metadata  |
1035    |   |                     | stored in the same table entry.                                                   |
1036    |   |                     |                                                                                   |
1037    +---+---------------------+-----------------------------------------------------------------------------------+
1038    | 3 | Send to table       | Send the current packet to specified table. The table ID is metadata stored in    |
1039    |   |                     | the same table entry.                                                             |
1040    |   |                     |                                                                                   |
1041    +---+---------------------+-----------------------------------------------------------------------------------+
1042
1043 User Actions
1044 ^^^^^^^^^^^^
1045
1046 For each table, the meaning of user actions is defined through the configuration of the table action handler.
1047 Different tables can be configured with different action handlers, therefore the meaning of the user actions
1048 and their associated meta-data is private to each table.
1049 Within the same table, all the table entries (including the table default entry) share the same definition
1050 for the user actions and their associated meta-data,
1051 with each table entry having its own set of enabled user actions and its own copy of the action meta-data.
1052 :numref:`table_qos_34` contains a non-exhaustive list of user action examples.
1053
1054 .. _table_qos_34:
1055
1056 .. table:: User Action Examples
1057
1058    +---+-----------------------------------+---------------------------------------------------------------------+
1059    | # | User action                       | Description                                                         |
1060    |   |                                   |                                                                     |
1061    +===+===================================+=====================================================================+
1062    | 1 | Metering                          | Per flow traffic metering using the srTCM and trTCM algorithms.     |
1063    |   |                                   |                                                                     |
1064    +---+-----------------------------------+---------------------------------------------------------------------+
1065    | 2 | Statistics                        | Update the statistics counters maintained per flow.                 |
1066    |   |                                   |                                                                     |
1067    +---+-----------------------------------+---------------------------------------------------------------------+
1068    | 3 | App ID                            | Per flow state machine fed by variable length sequence of packets   |
1069    |   |                                   | at the flow initialization with the purpose of identifying the      |
1070    |   |                                   | traffic type and application.                                       |
1071    |   |                                   |                                                                     |
1072    +---+-----------------------------------+---------------------------------------------------------------------+
1073    | 4 | Push/pop labels                   | Push/pop VLAN/MPLS labels to/from the current packet.               |
1074    |   |                                   |                                                                     |
1075    +---+-----------------------------------+---------------------------------------------------------------------+
1076    | 5 | Network Address Translation (NAT) | Translate between the internal (LAN) and external (WAN) IP          |
1077    |   |                                   | destination/source address and/or L4 protocol destination/source    |
1078    |   |                                   | port.                                                               |
1079    |   |                                   |                                                                     |
1080    +---+-----------------------------------+---------------------------------------------------------------------+
1081    | 6 | TTL update                        | Decrement IP TTL and, in case of IPv4 packets, update the IP        |
1082    |   |                                   | checksum.                                                           |
1083    |   |                                   |                                                                     |
1084    +---+-----------------------------------+---------------------------------------------------------------------+
1085    | 7 | Sym Crypto                        | Generate Cryptodev session based on the user-specified algorithm    |
1086    |   |                                   | and key(s), and assemble the cryptodev operation based on the       |
1087    |   |                                   | predefined offsets.                                                 |
1088    |   |                                   |                                                                     |
1089    +---+-----------------------------------+---------------------------------------------------------------------+
1090
1091 Multicore Scaling
1092 -----------------
1093
1094 A complex application is typically split across multiple cores, with cores communicating through SW queues.
1095 There is usually a performance limit on the number of table lookups
1096 and actions that can be fitted on the same CPU core due to HW constraints like:
1097 available CPU cycles, cache memory size, cache transfer BW, memory transfer BW, etc.
1098
1099 As the application is split across multiple CPU cores, the Packet Framework facilitates the creation of several pipelines,
1100 the assignment of each such pipeline to a different CPU core
1101 and the interconnection of all CPU core-level pipelines into a single application-level complex pipeline.
1102 For example, if CPU core A is assigned to run pipeline P1 and CPU core B pipeline P2,
1103 then the interconnection of P1 with P2 could be achieved by having the same set of SW queues act like output ports
1104 for P1 and input ports for P2.
1105
1106 This approach enables the application development using the pipeline, run-to-completion (clustered) or hybrid (mixed) models.
1107
1108 It is allowed for the same core to run several pipelines, but it is not allowed for several cores to run the same pipeline.
1109
1110 Shared Data Structures
1111 ~~~~~~~~~~~~~~~~~~~~~~
1112
1113 The threads performing table lookup are actually table writers rather than just readers.
1114 Even if the specific table lookup algorithm is thread-safe for multiple readers
1115 (e. g. read-only access of the search algorithm data structures is enough to conduct the lookup operation),
1116 once the table entry for the current packet is identified, the thread is typically expected to update the action meta-data stored in the table entry
1117 (e.g. increment the counter tracking the number of packets that hit this table entry), and thus modify the table entry.
1118 During the time this thread is accessing this table entry (either writing or reading; duration is application specific),
1119 for data consistency reasons, no other threads (threads performing table lookup or entry add/delete operations) are allowed to modify this table entry.
1120
1121 Mechanisms to share the same table between multiple threads:
1122
1123 #.  **Multiple writer threads.**
1124     Threads need to use synchronization primitives like semaphores (distinct semaphore per table entry) or atomic instructions.
1125     The cost of semaphores is usually high, even when the semaphore is free.
1126     The cost of atomic instructions is normally higher than the cost of regular instructions.
1127
1128 #.  **Multiple writer threads, with single thread performing table lookup operations and multiple threads performing table entry add/delete operations.**
1129     The threads performing table entry add/delete operations send table update requests to the reader (typically through message passing queues),
1130     which does the actual table updates and then sends the response back to the request initiator.
1131
1132 #.  **Single writer thread performing table entry add/delete operations and multiple reader threads that perform table lookup operations with read-only access to the table entries.**
1133     The reader threads use the main table copy while the writer is updating the mirror copy.
1134     Once the writer update is done, the writer can signal to the readers and busy wait until all readers swaps between the mirror copy (which now becomes the main copy) and
1135     the mirror copy (which now becomes the main copy).
1136
1137 Interfacing with Accelerators
1138 -----------------------------
1139
1140 The presence of accelerators is usually detected during the initialization phase by inspecting the HW devices that are part of the system (e.g. by PCI bus enumeration).
1141 Typical devices with acceleration capabilities are:
1142
1143 *   Inline accelerators: NICs, switches, FPGAs, etc;
1144
1145 *   Look-aside accelerators: chipsets, FPGAs, Intel QuickAssist, etc.
1146
1147 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,
1148 with all the implementations sharing the same API: pure SW implementation (no acceleration), implementation using accelerator A, implementation using accelerator B, etc.
1149 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,
1150 with no application changes required.
1151
1152 The Software Switch (SWX) Pipeline
1153 ----------------------------------
1154
1155 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
1156 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
1157 the P4 programs to be translated to the DPDK SWX API and run on multi-core CPUs.
1158
1159 The main features of the SWX pipeline are:
1160
1161 *   Nothing is hard-wired, everything is dynamically defined: The packet headers (i.e. the network protocols), the packet meta-data, the actions, the tables
1162     and the pipeline itself are dynamically defined instead of selected from a predefined set.
1163
1164 *   Instructions: The actions and the life of the packet through the pipeline are defined with instructions that manipulate the pipeline objects mentioned
1165     above. The pipeline is the main function of the packet program, with actions as subroutines triggered by the tables.
1166
1167 *   Call external plugins: Extern objects and functions can be defined to call functionality that cannot be efficiently implemented with the existing
1168     pipeline-oriented instruction set, such as: error detecting/correcting codes, cryptographic operations, meters, statistics counter arrays, heuristics, etc.
1169
1170 *   Better control plane interaction: Transaction-oriented table update mechanism that supports multi-table atomic updates. Multiple tables can be updated in a
1171     single step with only the before-update and the after-update table entries visible to the packets. Alignment with the P4Runtime [3] protocol.
1172
1173 *   Performance: Multiple packets are in-flight within the pipeline at any moment. Each packet is owned by a different time-sharing thread in
1174     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.
1175     The instructions are verified and translated at initialization time with no run-time impact. The instructions are also optimized to detect and "fuse"
1176     frequently used patterns into vector-like instructions transparently to the user.
1177
1178 The main SWX pipeline components are:
1179
1180 *   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
1181     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
1182     performance reasons.
1183
1184 *   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
1185     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
1186     each field having a unique name and a constant size.
1187
1188 *   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,
1189     which is likely executed immediately after the packet reception. As result of the extract operation, each header is logically removed from the packet, so
1190     once the packet parsing operation is completed, the input packet is reduced to opaque payload. Just before transmission, one or several headers are pushed
1191     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
1192     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
1193     of each packet header is defined by instantiating a structure type.
1194
1195 *   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
1196     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
1197     instantiating a structure type.
1198
1199 *   Extern objects and functions: Used to plug into the pipeline any functionality that cannot be efficiently implemented with the existing pipeline instruction
1200     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
1201     extern object member functions or the extern function.  The mailbox format is defined by instantiating a structure type.
1202
1203 *   Instructions: The pipeline and its actions are defined with instructions from a predefined instruction set. The instructions are used to receive and
1204     transmit the current packet, extract and emit headers from/into the packet, read/write the packet headers, packet meta-data and mailboxes, start table
1205     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
1206     for the complete list of instructions.
1207
1208 *   Actions: The pipeline actions are dynamically defined through instructions as opposed to predefined. Essentially, the actions are subroutines of the
1209     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
1210     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
1211     actions have read-write access to the packet headers and meta-data.
1212
1213 *   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
1214     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
1215     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
1216     operation.
1217
1218 *   Pipeline: The pipeline represents the main program that defines the life of the packet, with subroutines (actions) executed on table lookup. As packets
1219     go through the pipeline, the packet headers and meta-data are transformed along the way.
1220
1221 References:
1222
1223 [1] P4-16 specification: https://p4.org/specs/
1224
1225 [2] P4-16 compiler: https://github.com/p4lang/p4c
1226
1227 [3] P4Runtime specification: https://p4.org/specs/