1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright 2018 The DPDK contributors 3 4.. _doc_guidelines: 5 6DPDK Documentation Guidelines 7============================= 8 9This document outlines the guidelines for writing the DPDK Guides and API documentation in RST and Doxygen format. 10 11It also explains the structure of the DPDK documentation and how to build it. 12 13 14Structure of the Documentation 15------------------------------ 16 17The DPDK source code repository contains input files to build the API documentation and User Guides. 18 19The main directories that contain files related to documentation are shown below:: 20 21 lib 22 |-- acl 23 |-- cfgfile 24 |-- cmdline 25 |-- eal 26 | |-- ... 27 ... 28 doc 29 |-- api 30 +-- guides 31 |-- freebsd_gsg 32 |-- linux_gsg 33 |-- prog_guide 34 |-- sample_app_ug 35 |-- guidelines 36 |-- testpmd_app_ug 37 |-- rel_notes 38 |-- nics 39 |-- ... 40 41 42The API documentation is built from `Doxygen <http://www.doxygen.nl>`_ comments in the header files. 43These files are mainly in the ``lib/*`` directories although some of the Poll Mode Drivers in ``drivers/net`` 44are also documented with Doxygen. 45 46The configuration files that are used to control the Doxygen output are in the ``doc/api`` directory. 47 48The user guides such as *The Programmers Guide* and the *FreeBSD* and *Linux Getting Started* Guides are generated 49from RST markup text files using the `Sphinx <http://sphinx-doc.org>`_ Documentation Generator. 50 51These files are included in the ``doc/guides/`` directory. 52The output is controlled by the ``doc/guides/conf.py`` file. 53 54 55Role of the Documentation 56------------------------- 57 58The following items outline the roles of the different parts of the documentation and when they need to be updated or 59added to by the developer. 60 61* **Release Notes** 62 63 The Release Notes document which features have been added in the current and previous releases of DPDK and highlight 64 any known issues. 65 The Releases Notes also contain notifications of features that will change ABI compatibility in the next release. 66 67 Developers should include updates to the Release Notes with patch sets that relate to any of the following sections: 68 69 * New Features 70 * Resolved Issues (see below) 71 * Known Issues 72 * API Changes 73 * ABI Changes 74 * Shared Library Versions 75 76 Resolved Issues should only include issues from previous releases that have been resolved in the current release. 77 Issues that are introduced and then fixed within a release cycle do not have to be included here. 78 79 Refer to the Release Notes from the previous DPDK release for the correct format of each section. 80 81 82* **API documentation** 83 84 The API documentation explains how to use the public DPDK functions. 85 The `API index page <https://doc.dpdk.org/api/>`_ shows the generated API documentation with related groups of functions. 86 87 The API documentation should be updated via Doxygen comments when new functions are added. 88 89* **Getting Started Guides** 90 91 The Getting Started Guides show how to install and configure DPDK and how to run DPDK based applications on different OSes. 92 93 A Getting Started Guide should be added when DPDK is ported to a new OS. 94 95* **The Programmers Guide** 96 97 The Programmers Guide explains how the API components of DPDK such as the EAL, Memzone, Rings and the Hash Library work. 98 It also describes some of the higher level functionality such as Packet Distributor and Packet Framework. 99 It also shows the build system and explains how to add applications. 100 101 The Programmers Guide should be expanded when new functionality is added to DPDK. 102 103* **App Guides** 104 105 The app guides document the DPDK applications in the ``app`` directory such as ``testpmd``. 106 107 The app guides should be updated if functionality is changed or added. 108 109* **Sample App Guides** 110 111 The sample app guides document the DPDK example applications in the examples directory. 112 Generally they demonstrate a major feature such as L2 or L3 Forwarding, Multi Process or Power Management. 113 They explain the purpose of the sample application, how to run it and step through some of the code to explain the 114 major functionality. 115 116 A new sample application should be accompanied by a new sample app guide. 117 The guide for the Skeleton Forwarding app is a good starting reference. 118 119* **Network Interface Controller Drivers** 120 121 The NIC Drivers document explains the features of the individual Poll Mode Drivers, such as software requirements, 122 configuration and initialization. 123 124 New documentation should be added for new Poll Mode Drivers. 125 126* **Guidelines** 127 128 The guideline documents record community process, expectations and design directions. 129 130 They can be extended, amended or discussed by submitting a patch and getting community approval. 131 132 133Building the Documentation 134-------------------------- 135 136.. _doc_dependencies: 137 138Dependencies 139~~~~~~~~~~~~ 140 141The following dependencies must be installed to build the documentation: 142 143* Doxygen. 144* Sphinx (also called python-sphinx). 145 146`Doxygen`_ generates documentation from commented source code. 147It can be installed as follows: 148 149.. code-block:: console 150 151 # Ubuntu/Debian. 152 sudo apt-get -y install doxygen 153 154 # Red Hat/Fedora. 155 sudo dnf -y install doxygen 156 157`Sphinx`_ is a Python documentation tool for converting RST files to HTML. 158For full support with figure and table captioning the latest version of Sphinx can be installed as follows: 159 160.. code-block:: console 161 162 # Ubuntu/Debian. 163 sudo apt-get -y install python3-sphinx python3-sphinx-rtd-theme 164 165 # Red Hat/Fedora. 166 sudo dnf -y install python3-sphinx python3-sphinx_rtd_theme 167 168For further information on getting started with Sphinx see the 169`Sphinx Getting Started <http://www.sphinx-doc.org/en/master/usage/quickstart.html>`_. 170 171.. Note:: 172 173 To get full support for Figure and Table numbering it is best to install Sphinx 1.3.1 or later. 174 175 176Build commands 177~~~~~~~~~~~~~~ 178 179The documentation is built using the standard DPDK build system. 180 181To build the documentation:: 182 183 ninja -C build doc 184 185See :doc:`../linux_gsg/build_dpdk` for more detail on compiling DPDK with meson. 186 187The output is generated in the directory ``build/doc/``, with: 188 189* HTML versions of the guide docs, e.g. Getting Started Guides, Programmers Guide, in ``build/doc/guides/html`` 190* HTML version of the API documentation in ``build/doc/api/html`` 191* Man-page version of the API documentation in ``build/doc/api/man``. 192 If not installing DPDK system-wise, these pages can be accessed by adding this directory to the ``MANPATH`` environment variable. 193 For example: 194 195.. code-block:: console 196 197 export MANPATH=:/path/to/build/doc/api/man 198 199.. Note:: 200 201 Make sure to fix any Sphinx or Doxygen warnings when adding or updating documentation. 202 203 204Document Guidelines 205------------------- 206 207Here are some guidelines in relation to the style of the documentation: 208 209* Document the obvious as well as the obscure since it won't always be obvious to the reader. 210 For example an instruction like "Set up 64 2MB Hugepages" is better when followed by a sample commandline or a link to 211 the appropriate section of the documentation. 212 213* Use American English spellings throughout. 214 This can be checked using the ``aspell`` utility:: 215 216 aspell --lang=en_US --check doc/guides/sample_app_ug/mydoc.rst 217 218 219RST Guidelines 220-------------- 221 222The RST (reStructuredText) format is a plain text markup format 223that can be converted to HTML or other formats. 224It is most closely associated with Python but it can be used to document any language. 225It is used in DPDK to document everything apart from the API. 226 227The Sphinx documentation contains a very useful `RST Primer <http://sphinx-doc.org/rest.html#rst-primer>`_ which is a 228good place to learn the minimal set of syntax required to format a document. 229 230The official `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ website contains the specification for the 231RST format and also examples of how to use it. 232However, for most developers the RST Primer is a better resource. 233 234The most common guidelines for writing RST text are detailed in the 235`Documenting Python <https://docs.python.org/devguide/documenting.html>`_ guidelines. 236The additional guidelines below reiterate or expand upon those guidelines. 237 238 239Line Length and Wrapping 240~~~~~~~~~~~~~~~~~~~~~~~~ 241 242* Documentation lines should be less than 100 characters. 243 244* Each sentence should start on a new line. 245 Multiple sentences, which are not separated by a blank line, 246 are joined automatically into paragraphs. 247 248* Wrap sentences at punctuation points, for example, at a comma. 249 If no punctuation, put the newline at a logical point in the sentence, 250 for example, at the end of a clause before an "and" or "but". 251 252* Lines in literal blocks should be less than 80 characters 253 since they are not wrapped by the document formatters. 254 255 Long literal command lines can be shown wrapped with backslashes. For 256 example:: 257 258 dpdk-testpmd -l 2-3 -n 4 \ 259 --vdev=virtio_user0,path=/dev/vhost-net,queues=2,queue_size=1024 \ 260 -- -i --tx-offloads=0x0000002c --enable-lro --txq=2 --rxq=2 \ 261 --txd=1024 --rxd=1024 262 263 264Whitespace 265~~~~~~~~~~ 266 267* Standard RST indentation is 3 spaces. 268 Code can be indented 4 spaces, especially if it is copied from source files. 269 270* No tabs. 271 Convert tabs in embedded code to 4 or 8 spaces. 272 273* No trailing whitespace. 274 275* Add 2 blank lines before each section header. 276 277* Add 1 blank line after each section header. 278 279* Add 1 blank line between each line of a list. 280 281 282Section Headers 283~~~~~~~~~~~~~~~ 284 285* Section headers should use the following underline formats:: 286 287 Level 1 Heading 288 =============== 289 290 291 Level 2 Heading 292 --------------- 293 294 295 Level 3 Heading 296 ~~~~~~~~~~~~~~~ 297 298 299 Level 4 Heading 300 ^^^^^^^^^^^^^^^ 301 302 303* Level 4 headings should be used sparingly. 304 305* The underlines should match the length of the text. 306 307* In general, the heading should be less than 80 characters, for conciseness. 308 309* As noted above: 310 311 * Add 2 blank lines before each section header. 312 313 * Add 1 blank line after each section header. 314 315 316Lists 317~~~~~ 318 319* Bullet lists should be formatted with a leading ``*`` as follows:: 320 321 * Item one. 322 323 * Item two is a long line that is wrapped and then indented to match 324 the start of the previous line. 325 326 * One space character between the bullet and the text is preferred. 327 328* Numbered lists can be formatted with a leading number but the preference is to use ``#.`` which will give automatic numbering. 329 This is more convenient when adding or removing items:: 330 331 #. Item one. 332 333 #. Item two is a long line that is wrapped and then indented to match 334 the start of the previous line. 335 336 #. Item three. 337 338* Definition lists can be written with or without a bullet:: 339 340 * Item one. 341 342 Some text about item one. 343 344 * Item two. 345 346 Some text about item two. 347 348* All lists, and sub-lists, must be separated from the preceding text by a blank line. 349 This is a syntax requirement. 350 351* All list items should be separated by a blank line for readability. 352 353 354Code and Literal block sections 355~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 356 357* Inline text that is required to be rendered with a fixed width font should be enclosed in backquotes like this: 358 \`\`text\`\`, so that it appears like this: ``text``. 359 360* Fixed width, literal blocks of texts should be indented at least 3 spaces and prefixed with ``::`` like this:: 361 362 Here is some fixed width text:: 363 364 0x0001 0x0001 0x00FF 0x00FF 365 366* It is also possible to specify an encoding for a literal block using the ``.. code-block::`` directive so that syntax 367 highlighting can be applied. 368 Examples of supported highlighting are:: 369 370 .. code-block:: console 371 .. code-block:: c 372 .. code-block:: python 373 .. code-block:: diff 374 .. code-block:: none 375 376 That can be applied as follows:: 377 378 .. code-block:: c 379 380 #include<stdio.h> 381 382 int main() { 383 384 printf("Hello World\n"); 385 386 return 0; 387 } 388 389 Which would be rendered as: 390 391 .. code-block:: c 392 393 #include<stdio.h> 394 395 int main() { 396 397 printf("Hello World\n"); 398 399 return 0; 400 } 401 402* Code snippets can also be included directly from the code using the ``literalinclude`` block. 403 Using this block instead of a code block will ensure that the code snippets 404 shown in the documentation are always up to date with the code. 405 406 The following will include a snippet from the skeleton sample app:: 407 408 .. literalinclude:: ../../../examples/skeleton/basicfwd.c 409 :language: c 410 :start-after: Display the port MAC address. 411 :end-before: Enable RX in promiscuous mode for the Ethernet device. 412 :dedent: 1 413 414 This would be rendered as: 415 416 .. literalinclude:: ../../../examples/skeleton/basicfwd.c 417 :language: c 418 :start-after: Display the port MAC address. 419 :end-before: Enable RX in promiscuous mode for the Ethernet device. 420 :dedent: 1 421 422 Specifying ``:language:`` will enable syntax highlighting for the specified language. 423 ``:dedent:`` is used in this example to remove 1 leading tab from each line of the snippet. 424 425* ``start-after`` and ``end-before`` can use any text within a given file, 426 however it may be difficult to find unique text within your code to mark the 427 start and end of your snippets. In these cases, it is recommended to include 428 explicit tags in your code to denote these locations for documentation purposes. 429 The accepted format for these comments is: 430 431 * Before the code snippet, create a new comment which is a sentence explaining 432 what the code snippet contains. The comment is terminated with a scissors ``8<``. 433 * After the code snippet, create another new comment which starts with a 434 scissors ``>8``, then ``End of`` and the first comment repeated. 435 * The scissors should be orientated as shown to make it clear what code is being snipped. 436 437 This can be done as follows: 438 439 .. code-block:: c 440 441 /* Example feature being documented. 8< */ 442 foo(bar); 443 /* >8 End of example feature being documented. */ 444 445 ``foo(bar);`` could then be included in the docs using:: 446 447 .. literalinclude:: ../../../examples/sample_app/main.c 448 :language: c 449 :start-after: Example feature being documented. 8< 450 :end-before: >8 End of example feature being documented. 451 452 If a multiline comment is needed before the snippet, 453 then the last line of the multiline comment should be in the same format as 454 the first comment shown in the example. 455 456* More information about the ``literalinclude`` block can be found within the 457 `Sphinx Documentation <https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html?highlight=literalinclude#directive-literalinclude>`_. 458 459* The default encoding for a literal block using the simplified ``::`` 460 directive is ``none``. 461 462* Lines in literal blocks should be less than 80 characters. 463 For long literal lines, try to wrap the text at sensible locations. 464 For example a long command line could be documented like this and still work if copied directly from the docs:: 465 466 ./<build_dir>/app/dpdk-testpmd -l 0-2 -n3 --vdev=net_pcap0,iface=eth0 \ 467 --vdev=net_pcap1,iface=eth1 \ 468 -- -i --nb-cores=2 --nb-ports=2 \ 469 --total-num-mbufs=2048 470 471* Long lines that cannot be wrapped, such as application output, should be truncated to be less than 80 characters. 472 473 474Images 475~~~~~~ 476 477* All images should be in SVG scalar graphics format. 478 They should be true SVG XML files and should not include binary formats embedded in a SVG wrapper. 479 480* The DPDK documentation contains some legacy images in PNG format. 481 These will be converted to SVG in time. 482 483* `Inkscape <http://inkscape.org>`_ is the recommended graphics editor for creating the images. 484 Use some of the older images in ``doc/guides/prog_guide/img/`` as a template, for example ``mbuf1.svg`` 485 or ``ring-enqueue1.svg``. 486 487* The SVG images should include a copyright notice, as an XML comment. 488 489* Images in the documentation should be formatted as follows: 490 491 * The image should be preceded by a label in the format ``.. _figure_XXXX:`` with a leading underscore and 492 where ``XXXX`` is a unique descriptive name. 493 494 * Images should be included using the ``.. figure::`` directive and the file type should be set to ``*`` (not ``.svg``). 495 This allows the format of the image to be changed if required, without updating the documentation. 496 497 * Images must have a caption as part of the ``.. figure::`` directive. 498 499* Here is an example of the previous three guidelines:: 500 501 .. _figure_mempool: 502 503 .. figure:: img/mempool.* 504 505 A mempool in memory with its associated ring. 506 507.. _mock_label: 508 509* Images can then be linked to using the ``:numref:`` directive:: 510 511 The mempool layout is shown in :numref:`figure_mempool`. 512 513 This would be rendered as: *The mempool layout is shown in* :ref:`Fig 6.3 <mock_label>`. 514 515 **Note**: The ``:numref:`` directive requires Sphinx 1.3.1 or later. 516 With earlier versions it will still be rendered as a link but won't have an automatically generated number. 517 518* The caption of the image can be generated, with a link, using the ``:ref:`` directive:: 519 520 :ref:`figure_mempool` 521 522 This would be rendered as: *A mempool in memory with its associated ring.* 523 524Tables 525~~~~~~ 526 527* RST tables should be used sparingly. 528 They are hard to format and to edit, and the same information 529 can usually be shown just as clearly with a definition or bullet list. 530 531* Tables in the documentation should be formatted as follows: 532 533 * The table should be preceded by a label in the format ``.. _table_XXXX:`` with a leading underscore and where 534 ``XXXX`` is a unique descriptive name. 535 536 * Tables should be included using the ``.. table::`` directive and must have a caption. 537 538* Here is an example of the previous two guidelines:: 539 540 .. _table_qos_pipes: 541 542 .. table:: Sample configuration for QOS pipes. 543 544 +----------+----------+----------+ 545 | Header 1 | Header 2 | Header 3 | 546 | | | | 547 +==========+==========+==========+ 548 | Text | Text | Text | 549 +----------+----------+----------+ 550 | ... | ... | ... | 551 +----------+----------+----------+ 552 553* Tables can be linked to using the ``:numref:`` and ``:ref:`` directives, as shown in the previous section for images. 554 For example:: 555 556 The QOS configuration is shown in :numref:`table_qos_pipes`. 557 558 559.. _links: 560 561Hyperlinks 562~~~~~~~~~~ 563 564* Links to external websites can be plain URLs. 565 The following is rendered as https://dpdk.org:: 566 567 https://dpdk.org 568 569* They can contain alternative text. 570 The following is rendered as `Check out DPDK <https://dpdk.org>`_:: 571 572 `Check out DPDK <https://dpdk.org>`_ 573 574* An internal link can be generated by placing labels in the document with the format ``.. _label_name``. 575 576* The following links to the top of this section: :ref:`links`:: 577 578 .. _links: 579 580 Hyperlinks 581 ~~~~~~~~~~ 582 583 * The following links to the top of this section: :ref:`links`: 584 585.. Note:: 586 587 The label must have a leading underscore but the reference to it must omit it. 588 This is a frequent cause of errors and warnings. 589 590* The use of a label is preferred since it works across files and will still work if the header text changes. 591 592 593.. _doxygen_guidelines: 594 595Doxygen Guidelines 596------------------ 597 598The DPDK API is documented using Doxygen comment annotations in the header files. 599Doxygen is a very powerful tool, it is extremely configurable and with a little effort can be used to create expressive documents. 600See the `Doxygen website <http://www.doxygen.nl>`_ for full details on how to use it. 601 602The following are some guidelines for use of Doxygen in the DPDK API documentation: 603 604* New libraries that are documented with Doxygen should be added to the Doxygen configuration file: ``doc/api/doxy-api.conf``. 605 It is only required to add the directory that contains the files. 606 It isn't necessary to explicitly name each file since the configuration matches all ``rte_*.h`` files in the directory. 607 608* Use proper capitalization and punctuation in the Doxygen comments since they will become sentences in the documentation. 609 This in particular applies to single line comments, which is the case the is most often forgotten. 610 611* Use ``@`` style Doxygen commands instead of ``\`` style commands. 612 613* Add a general description of each library at the head of the main header files: 614 615 .. code-block:: c 616 617 /** 618 * @file 619 * RTE Mempool. 620 * 621 * A memory pool is an allocator of fixed-size object. It is 622 * identified by its name, and uses a ring to store free objects. 623 * ... 624 */ 625 626* Document the purpose of a function, the parameters used and the return 627 value: 628 629 .. code-block:: c 630 631 /** 632 * Try to take the lock. 633 * 634 * @param sl 635 * A pointer to the spinlock. 636 * @return 637 * 1 if the lock is successfully taken; 0 otherwise. 638 */ 639 int rte_spinlock_trylock(rte_spinlock_t *sl); 640 641* Doxygen supports Markdown style syntax such as bold, italics, fixed width text and lists. 642 For example the second line in the ``devargs`` parameter in the previous example will be rendered as: 643 644 The strings should be a pci address like ``0000:01:00.0`` or **virtual** device name like ``net_pcap0``. 645 646* Use ``-`` instead of ``*`` for lists within the Doxygen comment since the latter can get confused with the comment delimiter. 647 648* Add an empty line between the function description, the ``@params`` and ``@return`` for readability. 649 650* Place the ``@params`` description on separate line and indent it by 2 spaces. 651 (It would be better to use no indentation since this is more common and also because checkpatch complains about leading 652 whitespace in comments. 653 However this is the convention used in the existing DPDK code.) 654 655* Documented functions can be linked to simply by adding ``()`` to the function name: 656 657 .. code-block:: c 658 659 /** 660 * The functions exported by the application Ethernet API to setup 661 * a device designated by its port identifier must be invoked in 662 * the following order: 663 * - rte_eth_dev_configure() 664 * - rte_eth_tx_queue_setup() 665 * - rte_eth_rx_queue_setup() 666 * - rte_eth_dev_start() 667 */ 668 669 In the API documentation the functions will be rendered as links, see the 670 `online section of the rte_ethdev.h docs <https://doc.dpdk.org/api/rte__ethdev_8h.html>`_ that contains the above text. 671 672* The ``@see`` keyword can be used to create a *see also* link to another file or library. 673 This directive should be placed on one line at the bottom of the documentation section. 674 675 .. code-block:: c 676 677 /** 678 * ... 679 * 680 * Some text that references mempools. 681 * 682 * @see eal_memzone.c 683 */ 684 685* Doxygen supports two types of comments for documenting variables, constants and members: prefix and postfix: 686 687 .. code-block:: c 688 689 /** This is a prefix comment. */ 690 #define RTE_FOO_ERROR 0x023. 691 692 #define RTE_BAR_ERROR 0x024. /**< This is a postfix comment. */ 693 694* Postfix comments are preferred for struct members and constants if they can be documented in the same way: 695 696 .. code-block:: c 697 698 struct rte_eth_stats { 699 uint64_t ipackets; /**< Total number of received packets. */ 700 uint64_t opackets; /**< Total number of transmitted packets.*/ 701 uint64_t ibytes; /**< Total number of received bytes. */ 702 uint64_t obytes; /**< Total number of transmitted bytes. */ 703 uint64_t imissed; /**< Total of RX missed packets. */ 704 uint64_t ibadcrc; /**< Total of RX packets with CRC error. */ 705 uint64_t ibadlen; /**< Total of RX packets with bad length. */ 706 } 707 708 Note: postfix comments should be aligned with spaces not tabs in accordance 709 with the :ref:`coding_style`. 710 711* If a single comment type can't be used, due to line length limitations then 712 prefix comments should be preferred. 713 For example this section of the code contains prefix comments, postfix comments on the same line and postfix 714 comments on a separate line: 715 716 .. code-block:: c 717 718 /** Number of elements in the elt_pa array. */ 719 alignas(RTE_CACHE_LINE_SIZE) uint32_t pg_num; 720 uint32_t pg_shift; /**< LOG2 of the physical pages. */ 721 uintptr_t pg_mask; /**< Physical page mask value. */ 722 uintptr_t elt_va_start; 723 /**< Virtual address of the first mempool object. */ 724 uintptr_t elt_va_end; 725 /**< Virtual address of the <size + 1> mempool object. */ 726 phys_addr_t elt_pa[1]; 727 /**< Array of physical page addresses for the mempool buffer. */ 728 729 This doesn't have an effect on the rendered documentation but it is confusing for the developer reading the code. 730 It this case it would be clearer to use prefix comments throughout: 731 732 .. code-block:: c 733 734 /** Number of elements in the elt_pa array. */ 735 alignas(RTE_CACHE_LINE_SIZE) uint32_t pg_num; 736 /** LOG2 of the physical pages. */ 737 uint32_t pg_shift; 738 /** Physical page mask value. */ 739 uintptr_t pg_mask; 740 /** Virtual address of the first mempool object. */ 741 uintptr_t elt_va_start; 742 /** Virtual address of the <size + 1> mempool object. */ 743 uintptr_t elt_va_end; 744 /** Array of physical page addresses for the mempool buffer. */ 745 phys_addr_t elt_pa[1]; 746 747* Read the rendered section of the documentation that you have added for correctness, clarity and consistency 748 with the surrounding text. 749
