1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright(c) 2015-2016 Intel Corporation. 3 4Internet Protocol (IP) Pipeline Application 5=========================================== 6 7Application overview 8-------------------- 9 10The *Internet Protocol (IP) Pipeline* application is intended to be a vehicle for rapid development of packet processing 11applications running on multi-core CPUs. 12 13The application provides a library of reusable functional blocks called pipelines. 14These pipelines can be seen as prefabricated blocks that can be instantiated and inter-connected through packet queues 15to create complete applications (super-pipelines). 16 17Pipelines are created and inter-connected through the application configuration file. 18By using different configuration files, different applications are effectively created, therefore this application 19can be seen as an application generator. 20The configuration of each pipeline can be updated at run-time through the application Command Line Interface (CLI). 21 22Main application components are: 23 24**A Library of reusable pipelines** 25 26 * Each pipeline represents a functional block, e.g. flow classification, firewall, routing, master, etc. 27 28 * Each pipeline type can be instantiated several times in the same application, which each instance configured 29 separately and mapped to a single CPU core. 30 Each CPU core can run one or several pipeline instances, which can be of same or different type. 31 32 * Pipeline instances are inter-connected through packet queues (for packet processing) and message queues 33 (for run-time configuration). 34 35 * Pipelines are implemented using DPDK Packet Framework. 36 37 * More pipeline types can always be built and added to the existing pipeline types. 38 39**The Configuration file** 40 41 * The configuration file defines the application structure. 42 By using different configuration files, different applications are created. 43 44 * All the application resources are created and configured through the application configuration file: 45 pipeline instances, buffer pools, links (i.e. network interfaces), hardware device RX/TX queues, 46 software queues, traffic manager devices, EAL startup arguments, etc. 47 48 * The configuration file syntax is “define by reference”, meaning that resources are defined as they are referenced. 49 First time a resource name is detected, it is registered with default parameters. 50 Optionally, the resource parameters can be further refined through a configuration file section dedicated to 51 that resource. 52 53 * Command Line Interface (CLI) 54 55**Global CLI commands: link configuration, etc.** 56 57 * Common pipeline CLI commands: ping (keep-alive), statistics, etc. 58 59 * Pipeline type specific CLI commands: used to configure instances of specific pipeline type. 60 These commands are registered with the application when the pipeline type is registered. 61 For example, the commands for routing pipeline instances include: route add, route delete, route list, etc. 62 63 * CLI commands can be grouped into scripts that can be invoked at initialization and at runtime. 64 65 66Design goals 67------------ 68 69 70Rapid development 71~~~~~~~~~~~~~~~~~ 72 73This application enables rapid development through quick connectivity of standard components called pipelines. 74These components are built using DPDK Packet Framework and encapsulate packet processing features at different levels: 75ports, tables, actions, pipelines and complete applications. 76 77Pipeline instances are instantiated, configured and inter-connected through low complexity configuration files loaded 78during application initialization. 79Each pipeline instance is mapped to a single CPU core, with each CPU core able to run one or multiple pipeline 80instances of same or different types. By loading a different configuration file, a different application is 81effectively started. 82 83 84Flexibility 85~~~~~~~~~~~ 86 87Each packet processing application is typically represented as a chain of functional stages which is often called 88the functional pipeline of the application. 89These stages are mapped to CPU cores to create chains of CPU cores (pipeline model), clusters of CPU cores 90(run-to-completion model) or chains of clusters of CPU cores (hybrid model). 91 92This application allows all the above programming models. 93By applying changes to the configuration file, the application provides the flexibility to reshuffle its 94building blocks in different ways until the configuration providing the best performance is identified. 95 96 97Move pipelines around 98^^^^^^^^^^^^^^^^^^^^^ 99 100The mapping of pipeline instances to CPU cores can be reshuffled through the configuration file. 101One or several pipeline instances can be mapped to the same CPU core. 102 103.. _figure_ip_pipelines_1: 104 105.. figure:: img/ip_pipelines_1.* 106 107 Example of moving pipeline instances across different CPU cores 108 109 110Move tables around 111^^^^^^^^^^^^^^^^^^ 112 113There is some degree of flexibility for moving tables from one pipeline instance to another. 114Based on the configuration arguments passed to each pipeline instance in the configuration file, specific tables 115can be enabled or disabled. 116This way, a specific table can be “moved” from pipeline instance A to pipeline instance B by simply disabling its 117associated functionality for pipeline instance A while enabling it for pipeline instance B. 118 119Due to requirement to have simple syntax for the configuration file, moving tables across different pipeline 120instances is not as flexible as the mapping of pipeline instances to CPU cores, or mapping actions to pipeline tables. 121Complete flexibility in moving tables from one pipeline to another could be achieved through a complex pipeline 122description language that would detail the structural elements of the pipeline (ports, tables and actions) and 123their connectivity, resulting in complex syntax for the configuration file, which is not acceptable. 124Good configuration file readability through simple syntax is preferred. 125 126*Example*: the IP routing pipeline can run the routing function only (with ARP function run by a different 127pipeline instance), or it can run both the routing and ARP functions as part of the same pipeline instance. 128 129 130.. _figure_ip_pipelines_2: 131 132.. figure:: img/ip_pipelines_2.* 133 134 Example of moving tables across different pipeline instances 135 136 137Move actions around 138^^^^^^^^^^^^^^^^^^^ 139 140When it makes sense, packet processing actions can be moved from one pipeline instance to another. 141Based on the configuration arguments passed to each pipeline instance in the configuration file, specific actions 142can be enabled or disabled. 143This way, a specific action can be "moved" from pipeline instance A to pipeline instance B by simply disabling its 144associated functionality for pipeline instance A while enabling it for pipeline instance B. 145 146*Example*: The flow actions of accounting, traffic metering, application identification, NAT, etc can be run as part 147of the flow classification pipeline instance or split across several flow actions pipeline instances, depending on 148the number of flow instances and their compute requirements. 149 150 151.. _figure_ip_pipelines_3: 152 153.. figure:: img/ip_pipelines_3.* 154 155 Example of moving actions across different tables and pipeline instances 156 157 158Performance 159~~~~~~~~~~~ 160 161Performance of the application is the highest priority requirement. 162Flexibility is not provided at the expense of performance. 163 164The purpose of flexibility is to provide an incremental development methodology that allows monitoring the 165performance evolution: 166 167* Apply incremental changes in the configuration (e.g. mapping on pipeline instances to CPU cores) 168 in order to identify the configuration providing the best performance for a given application; 169 170* Add more processing incrementally (e.g. by enabling more actions for specific pipeline instances) until 171 the application is feature complete while checking the performance impact at each step. 172 173 174Debug capabilities 175~~~~~~~~~~~~~~~~~~ 176 177The application provides a significant set of debug capabilities: 178 179* Command Line Interface (CLI) support for statistics polling: pipeline instance ping (keep-alive checks), 180 pipeline instance statistics per input port/output port/table, link statistics, etc; 181 182* Logging: Turn on/off application log messages based on priority level; 183 184Running the application 185----------------------- 186 187The application startup command line is:: 188 189 ip_pipeline [-f CONFIG_FILE] [-s SCRIPT_FILE] -p PORT_MASK [-l LOG_LEVEL] 190 191The application startup arguments are: 192 193``-f CONFIG_FILE`` 194 195 * Optional: Yes 196 197 * Default: ``./config/ip_pipeline.cfg`` 198 199 * Argument: Path to the configuration file to be loaded by the application. 200 Please refer to the :ref:`ip_pipeline_configuration_file` for details on how to write the configuration file. 201 202``-s SCRIPT_FILE`` 203 204 * Optional: Yes 205 206 * Default: Not present 207 208 * Argument: Path to the CLI script file to be run by the master pipeline at application startup. 209 No CLI script file will be run at startup if this argument is not present. 210 211``-p PORT_MASK`` 212 213 * Optional: No 214 215 * Default: N/A 216 217 * Argument: Hexadecimal mask of NIC port IDs to be used by the application. 218 First port enabled in this mask will be referenced as LINK0 as part of the application configuration file, 219 next port as LINK1, etc. 220 221``-l LOG_LEVEL`` 222 223 * Optional: Yes 224 225 * Default: 1 (High priority) 226 227 * Argument: Log level to determine which application messages are to be printed to standard output. 228 Available log levels are: 0 (None), 1 (High priority), 2 (Low priority). 229 Only application messages whose priority is higher than or equal to the application log level will be printed. 230 231 232Application stages 233------------------ 234 235 236Configuration 237~~~~~~~~~~~~~ 238 239During this stage, the application configuration file is parsed and its content is loaded into the application data 240structures. 241In case of any configuration file parse error, an error message is displayed and the application is terminated. 242Please refer to the :ref:`ip_pipeline_configuration_file` for a description of the application configuration file format. 243 244 245Configuration checking 246~~~~~~~~~~~~~~~~~~~~~~ 247 248In the absence of any parse errors, the loaded content of application data structures is checked for overall consistency. 249In case of any configuration check error, an error message is displayed and the application is terminated. 250 251 252Initialization 253~~~~~~~~~~~~~~ 254 255During this stage, the application resources are initialized and the handles to access them are saved into the 256application data structures. 257In case of any initialization error, an error message is displayed and the application is terminated. 258 259The typical resources to be initialized are: pipeline instances, buffer pools, links (i.e. network interfaces), 260hardware device RX/TX queues, software queues, traffic management devices, etc. 261 262 263.. _ip_pipeline_runtime: 264 265Run-time 266~~~~~~~~ 267 268Each CPU core runs the pipeline instances assigned to it in time sharing mode and in round robin order: 269 2701. *Packet processing task*: The pipeline run-time code is typically a packet *processing* task built on top of 271 DPDK Packet Framework rte_pipeline library, which reads bursts of packets from the pipeline input ports, 272 performs table lookups and executes the identified actions for all tables in the pipeline, with packet 273 eventually written to pipeline output ports or dropped. 274 2752. *Message handling task*: Each CPU core will also periodically execute the *message handling* code of each 276 of the pipelines mapped to it. 277 The pipeline message handling code is processing the messages that are pending in the pipeline input message 278 queues, which are typically sent by the master CPU core for the on-the-fly pipeline configuration: check 279 that pipeline is still alive (ping), add/delete entries in the pipeline tables, get statistics, etc. 280 The frequency of executing the message handling code is usually much smaller than the frequency of executing 281 the packet processing work. 282 283Please refer to the :ref:`ip_pipeline_pipeline_section` for more details about the application pipeline module encapsulation. 284 285.. _ip_pipeline_configuration_file: 286 287Configuration file syntax 288------------------------- 289 290Syntax overview 291~~~~~~~~~~~~~~~ 292 293The syntax of the configuration file is designed to be simple, which favors readability. 294The configuration file is parsed using the DPDK library librte_cfgfile, which supports simple 295`INI file format <http://en.wikipedia.org/wiki/INI_file>`__ for configuration files. 296 297As result, the configuration file is split into several sections, with each section containing one or more entries. 298The scope of each entry is its section, and each entry specifies a variable that is assigned a specific value. 299Any text after the ``;`` character is considered a comment and is therefore ignored. 300 301The following are application specific: number of sections, name of each section, number of entries of each section, 302name of the variables used for each section entry, the value format (e.g. signed/unsigned integer, string, etc) 303and range of each section entry variable. 304 305Generic example of configuration file section: 306 307.. code-block:: ini 308 309 [<section_name>] 310 311 <variable_name_1> = <value_1> 312 313 ; ... 314 315 <variable_name_N> = <value_N> 316 317 318Application resources present in the configuration file 319~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 320 321.. _table_ip_pipelines_resource_name: 322 323.. tabularcolumns:: |p{4cm}|p{6cm}|p{6cm}| 324 325.. table:: Application resource names in the configuration file 326 327 +----------------------------+-----------------------------+-------------------------------------------------+ 328 | Resource type | Format | Examples | 329 +============================+=============================+=================================================+ 330 | Pipeline | ``PIPELINE<ID>`` | ``PIPELINE0``, ``PIPELINE1`` | 331 +----------------------------+-----------------------------+-------------------------------------------------+ 332 | Mempool | ``MEMPOOL<ID>`` | ``MEMPOOL0``, ``MEMPOOL1`` | 333 +----------------------------+-----------------------------+-------------------------------------------------+ 334 | Link (network interface) | ``LINK<ID>`` | ``LINK0``, ``LINK1`` | 335 +----------------------------+-----------------------------+-------------------------------------------------+ 336 | Link RX queue | ``RXQ<LINK_ID>.<QUEUE_ID>`` | ``RXQ0.0``, ``RXQ1.5`` | 337 +----------------------------+-----------------------------+-------------------------------------------------+ 338 | Link TX queue | ``TXQ<LINK_ID>.<QUEUE_ID>`` | ``TXQ0.0``, ``TXQ1.5`` | 339 +----------------------------+-----------------------------+-------------------------------------------------+ 340 | Software queue | ``SWQ<ID>`` | ``SWQ0``, ``SWQ1`` | 341 +----------------------------+-----------------------------+-------------------------------------------------+ 342 | Traffic Manager | ``TM<LINK_ID>`` | ``TM0``, ``TM1`` | 343 +----------------------------+-----------------------------+-------------------------------------------------+ 344 | KNI (kernel NIC interface) | ``KNI<LINK_ID>`` | ``KNI0``, ``KNI1`` | 345 +----------------------------+-----------------------------+-------------------------------------------------+ 346 | Source | ``SOURCE<ID>`` | ``SOURCE0``, ``SOURCE1`` | 347 +----------------------------+-----------------------------+-------------------------------------------------+ 348 | Sink | ``SINK<ID>`` | ``SINK0``, ``SINK1`` | 349 +----------------------------+-----------------------------+-------------------------------------------------+ 350 | Message queue | ``MSGQ<ID>`` | ``MSGQ0``, ``MSGQ1``, | 351 | | ``MSGQ-REQ-PIPELINE<ID>`` | ``MSGQ-REQ-PIPELINE2``, ``MSGQ-RSP-PIPELINE2,`` | 352 | | ``MSGQ-RSP-PIPELINE<ID>`` | ``MSGQ-REQ-CORE-s0c1``, ``MSGQ-RSP-CORE-s0c1`` | 353 | | ``MSGQ-REQ-CORE-<CORE_ID>`` | | 354 | | ``MSGQ-RSP-CORE-<CORE_ID>`` | | 355 +----------------------------+-----------------------------+-------------------------------------------------+ 356 357``LINK`` instances are created implicitly based on the ``PORT_MASK`` application startup argument. 358``LINK0`` is the first port enabled in the ``PORT_MASK``, port 1 is the next one, etc. 359The LINK ID is different than the DPDK PMD-level NIC port ID, which is the actual position in the bitmask mentioned above. 360For example, if bit 5 is the first bit set in the bitmask, then ``LINK0`` is having the PMD ID of 5. 361This mechanism creates a contiguous LINK ID space and isolates the configuration file against changes in the board 362PCIe slots where NICs are plugged in. 363 364``RXQ``, ``TXQ``, ``TM`` and ``KNI`` instances have the LINK ID as part of their name. 365For example, ``RXQ2.1``, ``TXQ2.1`` and ``TM2`` are all associated with ``LINK2``. 366 367 368Rules to parse the configuration file 369~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 370 371The main rules used to parse the configuration file are: 372 3731. Application resource name determines the type of resource based on the name prefix. 374 375 *Example*: all software queues need to start with ``SWQ`` prefix, so ``SWQ0`` and ``SWQ5`` are valid software 376 queue names. 377 3782. An application resource is defined by creating a configuration file section with its name. 379 The configuration file section allows fine tuning on any of the resource parameters. 380 Some resource parameters are mandatory, in which case it is required to have them specified as part of the 381 section, while some others are optional, in which case they get assigned their default value when not present. 382 383 *Example*: section ``SWQ0`` defines a software queue named SWQ0, whose parameters are detailed as part of this section. 384 3853. An application resource can also be defined by referencing it. 386 Referencing a resource takes place by simply using its name as part of the value assigned to a variable in any 387 configuration file section. 388 In this case, the resource is registered with all its parameters having their default values. 389 Optionally, a section with the resource name can be added to the configuration file to fine tune some or all 390 of the resource parameters. 391 392 *Example*: in section ``PIPELINE3``, variable ``pktq_in`` includes ``SWQ5`` as part of its list, which results 393 in defining a software queue named ``SWQ5``; when there is no ``SWQ5`` section present in the configuration file, 394 ``SWQ5`` gets registered with default parameters. 395 396 397.. _ip_pipeline_pipeline_section: 398 399PIPELINE section 400~~~~~~~~~~~~~~~~ 401 402.. _table_ip_pipelines_pipeline_section_1: 403 404.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}| 405 406.. table:: Configuration file PIPELINE section (1/2) 407 408 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 409 | Section | Description | Optional | Range | Default value | 410 +===============+===========================================================+===============+========================+================+ 411 | type | Pipeline type. Defines the functionality to be | NO | See "List | N/A | 412 | | executed. | | of pipeline types" | | 413 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 414 | core | CPU core to run the current pipeline. | YES | See "CPU Core | CPU socket 0, | 415 | | | | notation" | core 0, | 416 | | | | | hyper-thread 0 | 417 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 418 | pktq_in | Packet queues to serve as input ports for the | YES | List of input | Empty list | 419 | | current pipeline instance. The acceptable packet | | packet queue IDs | | 420 | | queue types are: ``RXQ``, ``SWQ``, ``TM`` and ``SOURCE``. | | | | 421 | | First device in this list is used as pipeline input port | | | | 422 | | 0, second as pipeline input port 1, etc. | | | | 423 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 424 | pktq_out | Packet queues to serve as output ports for the | YES | List of output | Empty list | 425 | | current pipeline instance. The acceptable packet | | packet queue IDs. | | 426 | | queue types are: ``TXQ``, ``SWQ``, ``TM`` and ``SINK``. | | | | 427 | | First device in this list is used as pipeline output | | | | 428 | | port 0, second as pipeline output port 1, etc. | | | | 429 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 430 431.. _table_ip_pipelines_pipeline_section_2: 432 433.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}| 434 435.. table:: Configuration file PIPELINE section (2/2) 436 437 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 438 | Section | Description | Optional | Range | Default value | 439 +===============+===========================================================+===============+========================+================+ 440 | msgq_in | Input message queues. These queues contain | YES | List of message | Empty list | 441 | | request messages that need to be handled by the | | queue IDs | | 442 | | current pipeline instance. The type and format of | | | | 443 | | request messages is defined by the pipeline type. | | | | 444 | | For each pipeline instance, there is an input | | | | 445 | | message queue defined implicitly, whose name is: | | | | 446 | | ``MSGQ-REQ-<PIPELINE_ID>``. This message queue | | | | 447 | | should not be mentioned as part of msgq_in list. | | | | 448 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 449 | msgq_out | Output message queues. These queues are used by | YES | List of message | Empty list | 450 | | the current pipeline instance to write response | | queue IDs | | 451 | | messages as result of request messages being | | | | 452 | | handled. The type and format of response | | | | 453 | | messages is defined by the pipeline type. | | | | 454 | | For each pipeline instance, there is an output | | | | 455 | | message queue defined implicitly, whose name is: | | | | 456 | | ``MSGQ-RSP-<PIPELINE_ID>``. This message queue | | | | 457 | | should not be mentioned as part of msgq_out list. | | | | 458 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 459 | timer_period | Time period, measured in milliseconds, | YES | milliseconds | 1 ms | 460 | | for handling the input message queues. | | | | 461 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 462 | <any other> | Arguments to be passed to the current pipeline | Depends on | Depends on | Depends on | 463 | | instance. Format of the arguments, their type, | pipeline type | pipeline type | pipeline type | 464 | | whether each argument is optional or mandatory | | | | 465 | | and its default value (when optional) are defined | | | | 466 | | by the pipeline type. | | | | 467 | | The value of the arguments is applicable to the | | | | 468 | | current pipeline instance only. | | | | 469 +---------------+-----------------------------------------------------------+---------------+------------------------+----------------+ 470 471 472CPU core notation 473^^^^^^^^^^^^^^^^^ 474 475The CPU Core notation is:: 476 477 <CPU core> ::= [s|S<CPU socket ID>][c|C]<CPU core ID>[h|H] 478 479For example:: 480 481 CPU socket 0, core 0, hyper-thread 0: 0, c0, s0c0 482 483 CPU socket 0, core 0, hyper-thread 1: 0h, c0h, s0c0h 484 485 CPU socket 3, core 9, hyper-thread 1: s3c9h 486 487 488MEMPOOL section 489~~~~~~~~~~~~~~~ 490 491.. _table_ip_pipelines_mempool_section: 492 493.. tabularcolumns:: |p{2.5cm}|p{6cm}|p{1.5cm}|p{1.5cm}|p{3cm}| 494 495.. table:: Configuration file MEMPOOL section 496 497 +---------------+-----------------------------------------------+----------+----------+---------------------------+ 498 | Section | Description | Optional | Type | Default value | 499 +===============+===============================================+==========+==========+===========================+ 500 | buffer_size | Buffer size (in bytes) for the current | YES | uint32_t | 2048 | 501 | | buffer pool. | | | + sizeof(struct rte_mbuf) | 502 | | | | | + HEADROOM | 503 +---------------+-----------------------------------------------+----------+----------+---------------------------+ 504 | pool_size | Number of buffers in the current buffer pool. | YES | uint32_t | 32K | 505 +---------------+-----------------------------------------------+----------+----------+---------------------------+ 506 | cache_size | Per CPU thread cache size (in number of | YES | uint32_t | 256 | 507 | | buffers) for the current buffer pool. | | | | 508 +---------------+-----------------------------------------------+----------+----------+---------------------------+ 509 | cpu | CPU socket ID where to allocate memory for | YES | uint32_t | 0 | 510 | | the current buffer pool. | | | | 511 +---------------+-----------------------------------------------+----------+----------+---------------------------+ 512 513 514LINK section 515~~~~~~~~~~~~ 516 517.. _table_ip_pipelines_link_section: 518 519.. tabularcolumns:: |p{3cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{2cm}| 520 521.. table:: Configuration file LINK section 522 523 +-----------------+----------------------------------------------+----------+----------+-------------------+ 524 | Section entry | Description | Optional | Type | Default value | 525 +=================+==============================================+==========+==========+===================+ 526 | arp_q | NIC RX queue where ARP packets should | YES | 0 .. 127 | 0 (default queue) | 527 | | be filtered. | | | | 528 +-----------------+----------------------------------------------+----------+----------+-------------------+ 529 | tcp_syn_local_q | NIC RX queue where TCP packets with SYN | YES | 0 .. 127 | 0 (default queue) | 530 | | flag should be filtered. | | | | 531 +-----------------+----------------------------------------------+----------+----------+-------------------+ 532 | ip_local_q | NIC RX queue where IP packets with local | YES | 0 .. 127 | 0 (default queue) | 533 | | destination should be filtered. | | | | 534 | | When TCP, UDP and SCTP local queues are | | | | 535 | | defined, they take higher priority than this | | | | 536 | | queue. | | | | 537 +-----------------+----------------------------------------------+----------+----------+-------------------+ 538 | tcp_local_q | NIC RX queue where TCP packets with local | YES | 0 .. 127 | 0 (default queue) | 539 | | destination should be filtered. | | | | 540 +-----------------+----------------------------------------------+----------+----------+-------------------+ 541 | udp_local_q | NIC RX queue where TCP packets with local | YES | 0 .. 127 | 0 (default queue) | 542 | | destination should be filtered. | | | | 543 +-----------------+----------------------------------------------+----------+----------+-------------------+ 544 | sctp_local_q | NIC RX queue where TCP packets with local | YES | 0 .. 127 | 0 (default queue) | 545 | | destination should be filtered. | | | | 546 +-----------------+----------------------------------------------+----------+----------+-------------------+ 547 | promisc | Indicates whether current link should be | YES | YES/NO | YES | 548 | | started in promiscuous mode. | | | | 549 +-----------------+----------------------------------------------+----------+----------+-------------------+ 550 551 552RXQ section 553~~~~~~~~~~~ 554 555.. _table_ip_pipelines_rxq_section: 556 557.. tabularcolumns:: |p{3cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{2cm}| 558 559.. table:: Configuration file RXQ section 560 561 +---------------+--------------------------------------------+----------+----------+---------------+ 562 | Section | Description | Optional | Type | Default value | 563 +===============+============================================+==========+==========+===============+ 564 | mempool | Mempool to use for buffer allocation for | YES | uint32_t | MEMPOOL0 | 565 | | current NIC RX queue. The mempool ID has | | | | 566 | | to be associated with a valid instance | | | | 567 | | defined in the mempool entry of the global | | | | 568 | | section. | | | | 569 +---------------+--------------------------------------------+----------+----------+---------------+ 570 | Size | NIC RX queue size (number of descriptors) | YES | uint32_t | 128 | 571 +---------------+--------------------------------------------+----------+----------+---------------+ 572 | burst | Read burst size (number of descriptors) | YES | uint32_t | 32 | 573 +---------------+--------------------------------------------+----------+----------+---------------+ 574 575 576TXQ section 577~~~~~~~~~~~ 578 579.. _table_ip_pipelines_txq_section: 580 581.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{2cm}|p{1.5cm}| 582 583.. table:: Configuration file TXQ section 584 585 +---------------+----------------------------------------------+----------+------------------+---------------+ 586 | Section | Description | Optional | Type | Default value | 587 +===============+==============================================+==========+==================+===============+ 588 | size | NIC TX queue size (number of descriptors) | YES | uint32_t | 512 | 589 | | | | power of 2 | | 590 | | | | > 0 | | 591 +---------------+----------------------------------------------+----------+------------------+---------------+ 592 | burst | Write burst size (number of descriptors) | YES | uint32_t | 32 | 593 | | | | power of 2 | | 594 | | | | 0 < burst < size | | 595 +---------------+----------------------------------------------+----------+------------------+---------------+ 596 | dropless | When dropless is set to NO, packets can be | YES | YES/NO | NO | 597 | | dropped if not enough free slots are | | | | 598 | | currently available in the queue, so the | | | | 599 | | write operation to the queue is non- | | | | 600 | | blocking. | | | | 601 | | When dropless is set to YES, packets cannot | | | | 602 | | be dropped if not enough free slots are | | | | 603 | | currently available in the queue, so the | | | | 604 | | write operation to the queue is blocking, as | | | | 605 | | the write operation is retried until enough | | | | 606 | | free slots become available and all the | | | | 607 | | packets are successfully written to the | | | | 608 | | queue. | | | | 609 +---------------+----------------------------------------------+----------+------------------+---------------+ 610 | n_retries | Number of retries. Valid only when dropless | YES | uint32_t | 0 | 611 | | is set to YES. When set to 0, it indicates | | | | 612 | | unlimited number of retries. | | | | 613 +---------------+----------------------------------------------+----------+------------------+---------------+ 614 615 616SWQ section 617~~~~~~~~~~~ 618 619.. _table_ip_pipelines_swq_section: 620 621.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}| 622 623.. table:: Configuration file SWQ section 624 625 +---------------+----------------------------------------------+----------+------------------+---------------+ 626 | Section | Description | Optional | Type | Default value | 627 +===============+==============================================+==========+==================+===============+ 628 | size | Queue size (number of packets) | YES | uint32_t | 256 | 629 | | | | power of 2 | | 630 +---------------+----------------------------------------------+----------+------------------+---------------+ 631 | burst_read | Read burst size (number of packets) | YES | uint32_t | 32 | 632 | | | | power of 2 | | 633 | | | | 0 < burst < size | | 634 +---------------+----------------------------------------------+----------+------------------+---------------+ 635 | burst_write | Write burst size (number of packets) | YES | uint32_t | 32 | 636 | | | | power of 2 | | 637 | | | | 0 < burst < size | | 638 +---------------+----------------------------------------------+----------+------------------+---------------+ 639 | dropless | When dropless is set to NO, packets can be | YES | YES/NO | NO | 640 | | dropped if not enough free slots are | | | | 641 | | currently available in the queue, so the | | | | 642 | | write operation to the queue is non- | | | | 643 | | blocking. | | | | 644 | | When dropless is set to YES, packets cannot | | | | 645 | | be dropped if not enough free slots are | | | | 646 | | currently available in the queue, so the | | | | 647 | | write operation to the queue is blocking, as | | | | 648 | | the write operation is retried until enough | | | | 649 | | free slots become available and all the | | | | 650 | | packets are successfully written to the | | | | 651 | | queue. | | | | 652 +---------------+----------------------------------------------+----------+------------------+---------------+ 653 | n_retries | Number of retries. Valid only when dropless | YES | uint32_t | 0 | 654 | | is set to YES. When set to 0, it indicates | | | | 655 | | unlimited number of retries. | | | | 656 +---------------+----------------------------------------------+----------+------------------+---------------+ 657 | cpu | CPU socket ID where to allocate memory | YES | uint32_t | 0 | 658 | | for this SWQ. | | | | 659 +---------------+----------------------------------------------+----------+------------------+---------------+ 660 661 662TM section 663~~~~~~~~~~ 664 665.. _table_ip_pipelines_tm_section: 666 667.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}| 668 669.. table:: Configuration file TM section 670 671 +---------------+---------------------------------------------+----------+----------+---------------+ 672 | Section | Description | Optional | Type | Default value | 673 +===============+=============================================+==========+==========+===============+ 674 | Cfg | File name to parse for the TM configuration | YES | string | tm_profile | 675 | | to be applied. The syntax of this file is | | | | 676 | | described in the examples/qos_sched DPDK | | | | 677 | | application documentation. | | | | 678 +---------------+---------------------------------------------+----------+----------+---------------+ 679 | burst_read | Read burst size (number of packets) | YES | uint32_t | 64 | 680 +---------------+---------------------------------------------+----------+----------+---------------+ 681 | burst_write | Write burst size (number of packets) | YES | uint32_t | 32 | 682 +---------------+---------------------------------------------+----------+----------+---------------+ 683 684 685KNI section 686~~~~~~~~~~~ 687 688.. _table_ip_pipelines_kni_section: 689 690.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}| 691 692.. table:: Configuration file KNI section 693 694 +---------------+----------------------------------------------+----------+------------------+---------------+ 695 | Section | Description | Optional | Type | Default value | 696 +===============+==============================================+==========+==================+===============+ 697 | core | CPU core to run the KNI kernel thread. | YES | See "CPU Core | Not set | 698 | | When core config is set, the KNI kernel | | notation" | | 699 | | thread will be bound to the particular core. | | | | 700 | | When core config is not set, the KNI kernel | | | | 701 | | thread will be scheduled by the OS. | | | | 702 +---------------+----------------------------------------------+----------+------------------+---------------+ 703 | mempool | Mempool to use for buffer allocation for | YES | uint32_t | MEMPOOL0 | 704 | | current KNI port. The mempool ID has | | | | 705 | | to be associated with a valid instance | | | | 706 | | defined in the mempool entry of the global | | | | 707 | | section. | | | | 708 +---------------+----------------------------------------------+----------+------------------+---------------+ 709 | burst_read | Read burst size (number of packets) | YES | uint32_t | 32 | 710 | | | | power of 2 | | 711 | | | | 0 < burst < size | | 712 +---------------+----------------------------------------------+----------+------------------+---------------+ 713 | burst_write | Write burst size (number of packets) | YES | uint32_t | 32 | 714 | | | | power of 2 | | 715 | | | | 0 < burst < size | | 716 +---------------+----------------------------------------------+----------+------------------+---------------+ 717 | dropless | When dropless is set to NO, packets can be | YES | YES/NO | NO | 718 | | dropped if not enough free slots are | | | | 719 | | currently available in the queue, so the | | | | 720 | | write operation to the queue is non- | | | | 721 | | blocking. | | | | 722 | | When dropless is set to YES, packets cannot | | | | 723 | | be dropped if not enough free slots are | | | | 724 | | currently available in the queue, so the | | | | 725 | | write operation to the queue is blocking, as | | | | 726 | | the write operation is retried until enough | | | | 727 | | free slots become available and all the | | | | 728 | | packets are successfully written to the | | | | 729 | | queue. | | | | 730 +---------------+----------------------------------------------+----------+------------------+---------------+ 731 | n_retries | Number of retries. Valid only when dropless | YES | uint64_t | 0 | 732 | | is set to YES. When set to 0, it indicates | | | | 733 | | unlimited number of retries. | | | | 734 +---------------+----------------------------------------------+----------+------------------+---------------+ 735 736 737SOURCE section 738~~~~~~~~~~~~~~ 739 740.. _table_ip_pipelines_source_section: 741 742.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{2cm}| 743 744.. table:: Configuration file SOURCE section 745 746 +---------------+---------------------------------------+----------+----------+---------------+ 747 | Section | Description | Optional | Type | Default value | 748 +===============+=======================================+==========+==========+===============+ 749 | Mempool | Mempool to use for buffer allocation. | YES | uint32_t | MEMPOOL0 | 750 +---------------+---------------------------------------+----------+----------+---------------+ 751 | Burst | Read burst size (number of packets) | | uint32_t | 32 | 752 +---------------+---------------------------------------+----------+----------+---------------+ 753 754 755SINK section 756~~~~~~~~~~~~ 757 758Currently, there are no parameters to be passed to a sink device, so 759SINK section is not allowed. 760 761MSGQ section 762~~~~~~~~~~~~ 763 764.. _table_ip_pipelines_msgq_section: 765 766.. tabularcolumns:: |p{2.5cm}|p{7cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}| 767 768.. table:: Configuration file MSGQ section 769 770 +---------+--------------------------------------------+----------+------------+---------------+ 771 | Section | Description | Optional | Type | Default value | 772 +=========+============================================+==========+============+===============+ 773 | size | Queue size (number of packets) | YES | uint32_t | 64 | 774 | | | | != 0 | | 775 | | | | power of 2 | | 776 +---------+--------------------------------------------+----------+------------+---------------+ 777 | cpu | CPU socket ID where to allocate memory for | YES | uint32_t | 0 | 778 | | the current queue. | | | | 779 +---------+--------------------------------------------+----------+------------+---------------+ 780 781 782EAL section 783~~~~~~~~~~~ 784 785The application generates the EAL parameters rather than reading them from the command line. 786 787The CPU core mask parameter is generated based on the core entry of all PIPELINE sections. 788All the other EAL parameters can be set from this section of the application configuration file. 789 790 791Library of pipeline types 792------------------------- 793 794Pipeline module 795~~~~~~~~~~~~~~~ 796 797A pipeline is a self-contained module that implements a packet processing function and is typically implemented on 798top of the DPDK Packet Framework *librte_pipeline* library. 799The application provides a run-time mechanism to register different pipeline types. 800 801Depending on the required configuration, each registered pipeline type (pipeline class) is instantiated one or 802several times, with each pipeline instance (pipeline object) assigned to one of the available CPU cores. 803Each CPU core can run one or more pipeline instances, which might be of same or different types. 804For more information of the CPU core threading model, please refer to the :ref:`ip_pipeline_runtime` section. 805 806 807Pipeline type 808^^^^^^^^^^^^^ 809 810Each pipeline type is made up of a back-end and a front-end. The back-end represents the packet processing engine 811of the pipeline, typically implemented using the DPDK Packet Framework libraries, which reads packets from the 812input packet queues, handles them and eventually writes them to the output packet queues or drops them. 813The front-end represents the run-time configuration interface of the pipeline, which is exposed as CLI commands. 814The front-end communicates with the back-end through message queues. 815 816.. _table_ip_pipelines_back_end: 817 818.. tabularcolumns:: |p{1cm}|p{2cm}|p{12cm}| 819 820.. table:: Pipeline back-end 821 822 +------------+------------------+--------------------------------------------------------------------+ 823 | Field name | Field type | Description | 824 +============+==================+====================================================================+ 825 | f_init | Function pointer | Function to initialize the back-end of the current pipeline | 826 | | | instance. Typical work implemented by this function for the | 827 | | | current pipeline instance: | 828 | | | Memory allocation; | 829 | | | Parse the pipeline type specific arguments; | 830 | | | Initialize the pipeline input ports, output ports and tables, | 831 | | | interconnect input ports to tables; | 832 | | | Set the message handlers. | 833 +------------+------------------+--------------------------------------------------------------------+ 834 | f_free | Function pointer | Function to free the resources allocated by the back-end of the | 835 | | | current pipeline instance. | 836 +------------+------------------+--------------------------------------------------------------------+ 837 | f_run | Function pointer | Set to NULL for pipelines implemented using the DPDK library | 838 | | | librte_pipeline (typical case), and to non-NULL otherwise. This | 839 | | | mechanism is made available to support quick integration of | 840 | | | legacy code. | 841 | | | This function is expected to provide the packet processing | 842 | | | related code to be called as part of the CPU thread dispatch | 843 | | | loop, so this function is not allowed to contain an infinite loop. | 844 +------------+------------------+--------------------------------------------------------------------+ 845 | f_timer | Function pointer | Function to read the pipeline input message queues, handle | 846 | | | the request messages, create response messages and write | 847 | | | the response queues. The format of request and response | 848 | | | messages is defined by each pipeline type, with the exception | 849 | | | of some requests which are mandatory for all pipelines (e.g. | 850 | | | ping, statistics). | 851 +------------+------------------+--------------------------------------------------------------------+ 852 853 854.. _table_ip_pipelines_front_end: 855 856.. tabularcolumns:: |p{1cm}|p{2cm}|p{12cm}| 857 858.. table:: Pipeline front-end 859 860 +------------+-----------------------+-------------------------------------------------------------------+ 861 | Field name | Field type | Description | 862 +============+=======================+===================================================================+ 863 | f_init | Function pointer | Function to initialize the front-end of the current pipeline | 864 | | | instance. | 865 +------------+-----------------------+-------------------------------------------------------------------+ 866 | f_post_init| Function pointer | Function to run once after f_init. | 867 +------------+-----------------------+-------------------------------------------------------------------+ 868 | f_track | Function pointer | See section Tracking pipeline output port to physical link. | 869 +------------+-----------------------+-------------------------------------------------------------------+ 870 | f_free | Function pointer | Function to free the resources allocated by the front-end of | 871 | | | the current pipeline instance. | 872 +------------+-----------------------+-------------------------------------------------------------------+ 873 | cmds | Array of CLI commands | Array of CLI commands to be registered to the application CLI | 874 | | | for the current pipeline type. Even though the CLI is executed | 875 | | | by a different pipeline (typically, this is the master pipeline), | 876 | | | from modularity perspective is more efficient to keep the | 877 | | | message client side (part of the front-end) together with the | 878 | | | message server side (part of the back-end). | 879 +------------+-----------------------+-------------------------------------------------------------------+ 880 881 882Tracking pipeline output port to physical link 883^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 884 885Each pipeline instance is a standalone block that does not have visibility into the other pipeline instances or 886the application-level pipeline inter-connectivity. 887In some cases, it is useful for a pipeline instance to get application level information related to pipeline 888connectivity, such as to identify the output link (e.g. physical NIC port) where one of its output ports connected, 889either directly or indirectly by traversing other pipeline instances. 890 891Tracking can be successful or unsuccessful. 892Typically, tracking for a specific pipeline instance is successful when each one of its input ports can be mapped 893to a single output port, meaning that all packets read from the current input port can only go out on a single 894output port. 895Depending on the pipeline type, some exceptions may be allowed: a small portion of the packets, considered exception 896packets, are sent out on an output port that is pre-configured for this purpose. 897 898For pass-through pipeline type, the tracking is always successful. 899For pipeline types as flow classification, firewall or routing, the tracking is only successful when the number of 900output ports for the current pipeline instance is 1. 901 902This feature is used by the IP routing pipeline for adding/removing implicit routes every time a link is brought 903up/down. 904 905 906Table copies 907^^^^^^^^^^^^ 908 909Fast table copy: pipeline table used by pipeline for the packet processing task, updated through messages, table 910data structures are optimized for lookup operation. 911 912Slow table copy: used by the configuration layer, typically updated through CLI commands, kept in sync with the fast 913copy (its update triggers the fast copy update). 914Required for executing advanced table queries without impacting the packet processing task, therefore the slow copy 915is typically organized using different criteria than the fast copy. 916 917Examples: 918 919* Flow classification: Search through current set of flows (e.g. list all flows with a specific source IP address); 920 921* Firewall: List rules in descending order of priority; 922 923* Routing table: List routes sorted by prefix depth and their type (local, remote, default); 924 925* ARP: List entries sorted per output interface. 926 927 928Packet meta-data 929^^^^^^^^^^^^^^^^ 930 931Packet meta-data field offsets provided as argument to pipeline instances are essentially defining the data structure 932for the packet meta-data used by the current application use-case. 933It is very useful to put it in the configuration file as a comment in order to facilitate the readability of the 934configuration file. 935 936The reason to use field offsets for defining the data structure for the packet meta-data is due to the C language 937limitation of not being able to define data structures at run-time. 938Feature to consider: have the configuration file parser automatically generate and print the data structure defining 939the packet meta-data for the current application use-case. 940 941Packet meta-data typically contains: 942 9431. Pure meta-data: intermediate data per packet that is computed internally, passed between different tables of 944 the same pipeline instance (e.g. lookup key for the ARP table is obtained from the routing table), or between 945 different pipeline instances (e.g. flow ID, traffic metering color, etc); 946 9472. Packet fields: typically, packet header fields that are read directly from the packet, or read from the packet 948 and saved (duplicated) as a working copy at a different location within the packet meta-data (e.g. Diffserv 949 5-tuple, IP destination address, etc). 950 951Several strategies are used to design the packet meta-data, as described in the next subsections. 952 953 954Store packet meta-data in a different cache line as the packet headers 955"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 956 957This approach is able to support protocols with variable header length, like MPLS, where the offset of IP header 958from the start of the packet (and, implicitly, the offset of the IP header in the packet buffer) is not fixed. 959Since the pipelines typically require the specification of a fixed offset to the packet fields (e.g. Diffserv 9605-tuple, used by the flow classification pipeline, or the IP destination address, used by the IP routing pipeline), 961the workaround is to have the packet RX pipeline copy these fields at fixed offsets within the packet meta-data. 962 963As this approach duplicates some of the packet fields, it requires accessing more cache lines per packet for filling 964in selected packet meta-data fields (on RX), as well as flushing selected packet meta-data fields into the 965packet (on TX). 966 967Example: 968 969.. code-block:: ini 970 971 972 ; struct app_pkt_metadata { 973 ; uint32_t ip_da; 974 ; uint32_t hash; 975 ; uint32_t flow_id; 976 ; uint32_t color; 977 ; } __attribute__((__packed__)); 978 ; 979 980 [PIPELINE1] 981 ; Packet meta-data offsets 982 ip_da_offset = 0; Used by: routing 983 hash_offset = 4; Used by: RX, flow classification 984 flow_id_offset = 8; Used by: flow classification, flow actions 985 color_offset = 12; Used by: flow actions, routing 986 987 988Overlay the packet meta-data in the same cache line with the packet headers 989""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 990 991This approach is minimizing the number of cache line accessed per packet by storing the packet metadata in the 992same cache line with the packet headers. 993To enable this strategy, either some headroom is reserved for meta-data at the beginning of the packet headers 994cache line (e.g. if 16 bytes are needed for meta-data, then the packet headroom can be set to 128+16 bytes, so 995that NIC writes the first byte of the packet at offset 16 from the start of the first packet cache line), 996or meta-data is reusing the space of some packet headers that are discarded from the packet (e.g. input Ethernet 997header). 998 999Example: 1000 1001.. code-block:: ini 1002 1003 ; struct app_pkt_metadata { 1004 ; uint8_t headroom[RTE_PKTMBUF_HEADROOM]; /* 128 bytes (default) */ 1005 ; union { 1006 ; struct { 1007 ; struct ether_hdr ether; /* 14 bytes */ 1008 ; struct qinq_hdr qinq; /* 8 bytes */ 1009 ; }; 1010 ; struct { 1011 ; uint32_t hash; 1012 ; uint32_t flow_id; 1013 ; uint32_t color; 1014 ; }; 1015 ; }; 1016 ; struct ipv4_hdr ip; /* 20 bytes */ 1017 ; } __attribute__((__packed__)); 1018 ; 1019 [PIPELINE2] 1020 ; Packet meta-data offsets 1021 qinq_offset = 142; Used by: RX, flow classification 1022 ip_da_offset = 166; Used by: routing 1023 hash_offset = 128; Used by: RX, flow classification 1024 flow_id_offset = 132; Used by: flow classification, flow actions 1025 color_offset = 136; Used by: flow actions, routing 1026 1027 1028List of pipeline types 1029~~~~~~~~~~~~~~~~~~~~~~ 1030 1031.. _table_ip_pipelines_types: 1032 1033.. tabularcolumns:: |p{3cm}|p{5cm}|p{4cm}|p{4cm}| 1034 1035.. table:: List of pipeline types provided with the application 1036 1037 +-----------------------+-----------------------------+-----------------------+------------------------------------------+ 1038 | Name | Table(s) | Actions | Messages | 1039 +=======================+=============================+=======================+==========================================+ 1040 | Pass-through | Passthrough | 1. Pkt metadata build | 1. Ping | 1041 | | | 2. Flow hash | 2. Stats | 1042 | Note: depending on | | 3. Pkt checks | | 1043 | port type, can be | | 4. Load balancing | | 1044 | used for RX, TX, IP | | | | 1045 | fragmentation, IP | | | | 1046 | reassembly or Traffic | | | | 1047 | Management | | | | 1048 +-----------------------+-----------------------------+-----------------------+------------------------------------------+ 1049 | Flow classification | Exact match | 1. Flow ID | 1. Ping | 1050 | | | | | 1051 | | * Key = byte array | 2. Flow stats | 2. Stats | 1052 | | (source: pkt metadata) | 3. Metering | 3. Flow stats | 1053 | | * Data = action dependent | 4. Network Address | 4. Action stats | 1054 | | | 5. Translation (NAT) | 5. Flow add/ update/ delete | 1055 | | | | 6. Default flow add/ update/ delete | 1056 | | | | 7. Action update | 1057 +-----------------------+-----------------------------+-----------------------+------------------------------------------+ 1058 | Flow actions | Array | 1. Flow stats | 1. Ping | 1059 | | | | | 1060 | | * Key = Flow ID | 2. Metering | 2. Stats | 1061 | | (source: pkt metadata) | 3. Network Address | 3. Action stats | 1062 | | * Data = action dependent | 4. Translation (NAT) | 4. Action update | 1063 +-----------------------+-----------------------------+-----------------------+------------------------------------------+ 1064 | Firewall | ACL | 1. Allow/Drop | 1. Ping | 1065 | | | | | 1066 | | * Key = n-tuple | | 2. Stats | 1067 | | (source: pkt headers) | | 3. Rule add/ update/ delete | 1068 | | * Data = none | | 4. Default rule add/ update/ delete | 1069 +-----------------------+-----------------------------+-----------------------+------------------------------------------+ 1070 | IP routing | LPM (IPv4 or IPv6, | 1. TTL decrement and | 1. Ping | 1071 | | depending on pipeline type) | 2. IPv4 checksum | 2. Stats | 1072 | | | | | 1073 | | * Key = IP destination | 3. update | 3. Route add/ update/ delete | 1074 | | (source: pkt metadata) | 4. Header | 4. Default route add/ update/ delete | 1075 | | * Data = Dependent on | 5. encapsulation | 5. ARP entry add/ update/ delete | 1076 | | actions and next hop | 6. (based on next hop | 6. Default ARP entry add/ update/ delete | 1077 | | type | 7. type) | | 1078 | | | | | 1079 | | Hash table (for ARP, only | | | 1080 | | | | | 1081 | | when ARP is enabled) | | | 1082 | | | | | 1083 | | * Key = (Port ID, | | | 1084 | | next hop IP address) | | | 1085 | | (source: pkt meta-data) | | | 1086 | | * Data: MAC address | | | 1087 +-----------------------+-----------------------------+-----------------------+------------------------------------------+ 1088 1089 1090 1091Command Line Interface (CLI) 1092---------------------------- 1093 1094Global CLI commands 1095~~~~~~~~~~~~~~~~~~~ 1096 1097.. _table_ip_pipelines_cli_commands: 1098 1099.. tabularcolumns:: |p{3cm}|p{6cm}|p{6cm}| 1100 1101.. table:: Global CLI commands 1102 1103 +---------+---------------------------------------+--------------------------------------------+ 1104 | Command | Description | Syntax | 1105 +=========+=======================================+============================================+ 1106 | run | Run CLI commands script file. | run <file> | 1107 | | | <file> = path to file with CLI commands to | 1108 | | | execute | 1109 +---------+---------------------------------------+--------------------------------------------+ 1110 | quit | Gracefully terminate the application. | quit | 1111 +---------+---------------------------------------+--------------------------------------------+ 1112 1113 1114CLI commands for link configuration 1115~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1116 1117.. _table_ip_pipelines_runtime_config: 1118 1119.. tabularcolumns:: |p{3cm}|p{6cm}|p{6cm}| 1120 1121.. table:: List of run-time configuration commands for link configuration 1122 1123 +-------------+--------------------+--------------------------------------------+ 1124 | Command | Description | Syntax | 1125 +=============+====================+============================================+ 1126 | link config | Link configuration | link <link ID> config <IP address> <depth> | 1127 +-------------+--------------------+--------------------------------------------+ 1128 | link up | Link up | link <link ID> up | 1129 +-------------+--------------------+--------------------------------------------+ 1130 | link down | Link down | link <link ID> down | 1131 +-------------+--------------------+--------------------------------------------+ 1132 | link ls | Link list | link ls | 1133 +-------------+--------------------+--------------------------------------------+ 1134 1135 1136CLI commands common for all pipeline types 1137~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1138 1139.. _table_ip_pipelines_mandatory: 1140 1141.. tabularcolumns:: |p{3cm}|p{6cm}|p{6cm}| 1142 1143.. table:: CLI commands mandatory for all pipelines 1144 1145 +--------------------+------------------------------------------------------+----------------------------------------------+ 1146 | Command | Description | Syntax | 1147 +====================+======================================================+==============================================+ 1148 | ping | Check whether specific pipeline instance is alive. | p <pipeline ID> ping | 1149 | | The master pipeline sends a ping request | | 1150 | | message to given pipeline instance and waits for | | 1151 | | a response message back. | | 1152 | | Timeout message is displayed when the response | | 1153 | | message is not received before the timer | | 1154 | | expires. | | 1155 +--------------------+------------------------------------------------------+----------------------------------------------+ 1156 | stats | Display statistics for specific pipeline input port, | p <pipeline ID> stats port in <port in ID> | 1157 | | output port or table. | p <pipeline ID> stats port out <port out ID> | 1158 | | | p <pipeline ID> stats table <table ID> | 1159 +--------------------+------------------------------------------------------+----------------------------------------------+ 1160 | input port enable | Enable given input port for specific pipeline | p <pipeline ID> port in <port ID> enable | 1161 | | instance. | | 1162 +--------------------+------------------------------------------------------+----------------------------------------------+ 1163 | input port disable | Disable given input port for specific pipeline | p <pipeline ID> port in <port ID> disable | 1164 | | instance. | | 1165 +--------------------+------------------------------------------------------+----------------------------------------------+ 1166 1167Pipeline type specific CLI commands 1168~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1169 1170The pipeline specific CLI commands are part of the pipeline type front-end. 1171