3 DPDK Documentation Guidelines
4 =============================
6 This document outlines the guidelines for writing the DPDK Guides and API documentation in RST and Doxygen format.
8 It also explains the structure of the DPDK documentation and shows how to build the Html and PDF versions of the documents.
11 Structure of the Documentation
12 ------------------------------
14 The DPDK source code repository contains input files to build the API documentation and User Guides.
16 The main directories that contain files related to documentation are shown below::
41 The API documentation is built from `Doxygen <http://www.stack.nl/~dimitri/doxygen/>`_ comments in the header files.
42 These files are mainly in the ``lib/librte_*`` directories although some of the Poll Mode Drivers in ``drivers/net``
43 are also documented with Doxygen.
45 The configuration files that are used to control the Doxygen output are in the ``doc/api`` directory.
47 The user guides such as *The Programmers Guide* and the *FreeBSD* and *Linux Getting Started* Guides are generated
48 from RST markup text files using the `Sphinx <http://sphinx-doc.org/index.html>`_ Documentation Generator.
50 These files are included in the ``doc/guides/`` directory.
51 The output is controlled by the ``doc/guides/conf.py`` file.
54 Role of the Documentation
55 -------------------------
57 The following items outline the roles of the different parts of the documentation and when they need to be updated or
58 added to by the developer.
62 The Release Notes document which features have been added in the current and previous releases of DPDK and highlight
64 The Releases Notes also contain notifications of features that will change ABI compatibility in the next major release.
66 Developers should include updates to the Release Notes with patch sets that relate to any of the following sections:
69 * Resolved Issues (see below)
73 * Shared Library Versions
75 Resolved Issues should only include issues from previous releases that have been resolved in the current release.
76 Issues that are introduced and then fixed within a release cycle do not have to be included here.
78 Refer to the Release Notes from the previous DPDK release for the correct format of each section.
81 * **API documentation**
83 The API documentation explains how to use the public DPDK functions.
84 The `API index page <http://dpdk.org/doc/api/>`_ shows the generated API documentation with related groups of functions.
86 The API documentation should be updated via Doxygen comments when new functions are added.
88 * **Getting Started Guides**
90 The Getting Started Guides show how to install and configure DPDK and how to run DPDK based applications on different OSes.
92 A Getting Started Guide should be added when DPDK is ported to a new OS.
94 * **The Programmers Guide**
96 The Programmers Guide explains how the API components of DPDK such as the EAL, Memzone, Rings and the Hash Library work.
97 It also explains how some higher level functionality such as Packet Distributor, Packet Framework and KNI work.
98 It also shows the build system and explains how to add applications.
100 The Programmers Guide should be expanded when new functionality is added to DPDK.
104 The app guides document the DPDK applications in the ``app`` directory such as ``testpmd``.
106 The app guides should be updated if functionality is changed or added.
108 * **Sample App Guides**
110 The sample app guides document the DPDK example applications in the examples directory.
111 Generally they demonstrate a major feature such as L2 or L3 Forwarding, Multi Process or Power Management.
112 They explain the purpose of the sample application, how to run it and step through some of the code to explain the
115 A new sample application should be accompanied by a new sample app guide.
116 The guide for the Skeleton Forwarding app is a good starting reference.
118 * **Network Interface Controller Drivers**
120 The NIC Drivers document explains the features of the individual Poll Mode Drivers, such as software requirements,
121 configuration and initialization.
123 New documentation should be added for new Poll Mode Drivers.
127 The guideline documents record community process, expectations and design directions.
129 They can be extended, amended or discussed by submitting a patch and getting community approval.
132 Building the Documentation
133 --------------------------
139 The following dependencies must be installed to build the documentation:
143 * Sphinx (also called python-sphinx).
145 * TexLive (at least TexLive-core, extra Latex support and extra fonts).
149 `Doxygen`_ generates documentation from commented source code.
150 It can be installed as follows:
152 .. code-block:: console
155 sudo apt-get -y install doxygen
158 sudo yum -y install doxygen
160 `Sphinx`_ is a Python documentation tool for converting RST files to Html or to PDF (via LaTeX).
161 It can be installed as follows:
163 .. code-block:: console
166 sudo apt-get -y install python-sphinx
169 sudo yum -y install python-sphinx
171 # Or, on any system with Python installed.
172 sudo easy_install -U sphinx
174 For further information on getting started with Sphinx see the `Sphinx Tutorial <http://sphinx-doc.org/tutorial.html>`_.
178 To get full support for Figure and Table numbering it is best to install Sphinx 1.3.1 or later.
181 `Inkscape`_ is a vector based graphics program which is used to create SVG images and also to convert SVG images to PDF images.
182 It can be installed as follows:
184 .. code-block:: console
187 sudo apt-get -y install inkscape
190 sudo yum -y install inkscape
192 `TexLive <http://www.tug.org/texlive/>`_ is an installation package for Tex/LaTeX.
193 It is used to generate the PDF versions of the documentation.
194 The main required packages can be installed as follows:
196 .. code-block:: console
199 sudo apt-get -y install texlive-latex-extra texlive-fonts-extra \
200 texlive-fonts-recommended
203 # Red Hat/Fedora, selective install.
204 sudo yum -y install texlive-collection-latexextra \
205 texlive-collection-fontsextra
211 The documentation is built using the standard DPDK build system.
212 Some examples are shown below:
214 * Generate all the documentation targets::
218 * Generate the Doxygen API documentation in Html::
222 * Generate the guides documentation in Html::
226 * Generate the guides documentation in Pdf::
230 The output of these commands is generated in the ``build`` directory::
243 Make sure to fix any Sphinx or Doxygen warnings when adding or updating documentation.
245 The documentation output files can be removed as follows::
253 Here are some guidelines in relation to the style of the documentation:
255 * Document the obvious as well as the obscure since it won't always be obvious to the reader.
256 For example an instruction like "Set up 64 2MB Hugepages" is better when followed by a sample commandline or a link to
257 the appropriate section of the documentation.
259 * Use American English spellings throughout.
260 This can be checked using the ``aspell`` utility::
262 aspell --lang=en_US --check doc/guides/sample_app_ug/mydoc.rst
268 The RST (reStructuredText) format is a plain text markup format that can be converted to Html, PDF or other formats.
269 It is most closely associated with Python but it can be used to document any language.
270 It is used in DPDK to document everything apart from the API.
272 The Sphinx documentation contains a very useful `RST Primer <http://sphinx-doc.org/rest.html#rst-primer>`_ which is a
273 good place to learn the minimal set of syntax required to format a document.
275 The official `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ website contains the specification for the
276 RST format and also examples of how to use it.
277 However, for most developers the RST Primer is a better resource.
279 The most common guidelines for writing RST text are detailed in the
280 `Documenting Python <https://docs.python.org/devguide/documenting.html>`_ guidelines.
281 The additional guidelines below reiterate or expand upon those guidelines.
287 * The recommended style for the DPDK documentation is to put sentences on separate lines.
288 This allows for easier reviewing of patches.
289 Multiple sentences which are not separated by a blank line are joined automatically into paragraphs, for example::
291 Here is an example sentence.
292 Long sentences over the limit shown below can be wrapped onto
294 These three sentences will be joined into the same paragraph.
296 This is a new paragraph, since it is separated from the
297 previous paragraph by a blank line.
299 This would be rendered as follows:
301 *Here is an example sentence.
302 Long sentences over the limit shown below can be wrapped onto
304 These three sentences will be joined into the same paragraph.*
306 *This is a new paragraph, since it is separated from the
307 previous paragraph by a blank line.*
310 * Long sentences should be wrapped at 120 characters +/- 10 characters. They should be wrapped at words.
312 * Lines in literal blocks must by less than 80 characters since they aren't wrapped by the document formatters
313 and can exceed the page width in PDF documents.
319 * Standard RST indentation is 3 spaces.
320 Code can be indented 4 spaces, especially if it is copied from source files.
323 Convert tabs in embedded code to 4 or 8 spaces.
325 * No trailing whitespace.
327 * Add 2 blank lines before each section header.
329 * Add 1 blank line after each section header.
331 * Add 1 blank line between each line of a list.
337 * Section headers should use the use the following underline formats::
355 * Level 4 headings should be used sparingly.
357 * The underlines should match the length of the text.
359 * In general, the heading should be less than 80 characters, for conciseness.
363 * Add 2 blank lines before each section header.
365 * Add 1 blank line after each section header.
371 * Bullet lists should be formatted with a leading ``*`` as follows::
375 * Item two is a long line that is wrapped and then indented to match
376 the start of the previous line.
378 * One space character between the bullet and the text is preferred.
380 * Numbered lists can be formatted with a leading number but the preference is to use ``#.`` which will give automatic numbering.
381 This is more convenient when adding or removing items::
385 #. Item two is a long line that is wrapped and then indented
386 to match the start of the e first line.
388 #. Item two is a long line that is wrapped and then indented to match
389 the start of the previous line.
391 * Definition lists can be written with or without a bullet::
395 Some text about item one.
399 Some text about item two.
401 * All lists, and sub-lists, must be separated from the preceding text by a blank line.
402 This is a syntax requirement.
404 * All list items should be separated by a blank line for readability.
407 Code and Literal block sections
408 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
410 * Inline text that is required to be rendered with a fixed width font should be enclosed in backquotes like this:
411 \`\`text\`\`, so that it appears like this: ``text``.
413 * Fixed width, literal blocks of texts should be indented at least 3 spaces and prefixed with ``::`` like this::
415 Here is some fixed width text::
417 0x0001 0x0001 0x00FF 0x00FF
419 * It is also possible to specify an encoding for a literal block using the ``.. code-block::`` directive so that syntax
420 highlighting can be applied.
421 Examples of supported highlighting are::
423 .. code-block:: console
425 .. code-block:: python
429 That can be applied as follows::
437 printf("Hello World\n");
442 Which would be rendered as:
450 printf("Hello World\n");
456 * The default encoding for a literal block using the simplified ``::``
457 directive is ``none``.
459 * Lines in literal blocks must be less than 80 characters since they can exceed the page width when converted to PDF documentation.
460 For long literal lines that exceed that limit try to wrap the text at sensible locations.
461 For example a long command line could be documented like this and still work if copied directly from the docs::
463 build/app/testpmd -c7 -n3 --vdev=eth_pcap0,iface=eth0 \
464 --vdev=eth_pcap1,iface=eth1 \
465 -- -i --nb-cores=2 --nb-ports=2 \
466 --total-num-mbufs=2048
468 * Long lines that cannot be wrapped, such as application output, should be truncated to be less than 80 characters.
474 * All images should be in SVG scalar graphics format.
475 They should be true SVG XML files and should not include binary formats embedded in a SVG wrapper.
477 * The DPDK documentation contains some legacy images in PNG format.
478 These will be converted to SVG in time.
480 * `Inkscape <http://inkscape.org>`_ is the recommended graphics editor for creating the images.
481 Use some of the older images in ``doc/guides/prog_guide/img/`` as a template, for example ``mbuf1.svg``
482 or ``ring-enqueue.svg``.
484 * The SVG images should include a copyright notice, as an XML comment.
486 * Images in the documentation should be formatted as follows:
488 * The image should be preceded by a label in the format ``.. _figure_XXXX:`` with a leading underscore and
489 where ``XXXX`` is a unique descriptive name.
491 * Images should be included using the ``.. figure::`` directive and the file type should be set to ``*`` (not ``.svg``).
492 This allows the format of the image to be changed if required, without updating the documentation.
494 * Images must have a caption as part of the ``.. figure::`` directive.
496 * Here is an example of the previous three guidelines::
500 .. figure:: img/mempool.*
502 A mempool in memory with its associated ring.
506 * Images can then be linked to using the ``:numref:`` directive::
508 The mempool layout is shown in :numref:`figure_mempool`.
510 This would be rendered as: *The mempool layout is shown in* :ref:`Fig 6.3 <mock_label>`.
512 **Note**: The ``:numref:`` directive requires Sphinx 1.3.1 or later.
513 With earlier versions it will still be rendered as a link but won't have an automatically generated number.
515 * The caption of the image can be generated, with a link, using the ``:ref:`` directive::
517 :ref:`figure_mempool`
519 This would be rendered as: *A mempool in memory with its associated ring.*
524 * RST tables should be used sparingly.
525 They are hard to format and to edit, they are often rendered incorrectly in PDF format, and the same information
526 can usually be shown just as clearly with a definition or bullet list.
528 * Tables in the documentation should be formatted as follows:
530 * The table should be preceded by a label in the format ``.. _table_XXXX:`` with a leading underscore and where
531 ``XXXX`` is a unique descriptive name.
533 * Tables should be included using the ``.. table::`` directive and must have a caption.
535 * Here is an example of the previous two guidelines::
539 .. table:: Sample configuration for QOS pipes.
541 +----------+----------+----------+
542 | Header 1 | Header 2 | Header 3 |
544 +==========+==========+==========+
545 | Text | Text | Text |
546 +----------+----------+----------+
548 +----------+----------+----------+
550 * Tables can be linked to using the ``:numref:`` and ``:ref:`` directives, as shown in the previous section for images.
553 The QOS configuration is shown in :numref:`table_qos_pipes`.
555 * Tables should not include merged cells since they are not supported by the PDF renderer.
563 * Links to external websites can be plain URLs.
564 The following is rendered as http://dpdk.org::
568 * They can contain alternative text.
569 The following is rendered as `Check out DPDK <http://dpdk.org>`_::
571 `Check out DPDK <http://dpdk.org>`_
573 * An internal link can be generated by placing labels in the document with the format ``.. _label_name``.
575 * The following links to the top of this section: :ref:`links`::
582 * The following links to the top of this section: :ref:`links`:
586 The label must have a leading underscore but the reference to it must omit it.
587 This is a frequent cause of errors and warnings.
589 * The use of a label is preferred since it works across files and will still work if the header text changes.
592 .. _doxygen_guidelines:
597 The DPDK API is documented using Doxygen comment annotations in the header files.
598 Doxygen is a very powerful tool, it is extremely configurable and with a little effort can be used to create expressive documents.
599 See the `Doxygen website <http://www.stack.nl/~dimitri/doxygen/>`_ for full details on how to use it.
601 The following are some guidelines for use of Doxygen in the DPDK API documentation:
603 * New libraries that are documented with Doxygen should be added to the Doxygen configuration file: ``doc/api/doxy-api.conf``.
604 It is only required to add the directory that contains the files.
605 It isn't necessary to explicitly name each file since the configuration matches all ``rte_*.h`` files in the directory.
607 * Use proper capitalization and punctuation in the Doxygen comments since they will become sentences in the documentation.
608 This in particular applies to single line comments, which is the case the is most often forgotten.
610 * Use ``@`` style Doxygen commands instead of ``\`` style commands.
612 * Add a general description of each library at the head of the main header files:
620 * A memory pool is an allocator of fixed-size object. It is
621 * identified by its name, and uses a ring to store free objects.
625 * Document the purpose of a function, the parameters used and the return
631 * Attach a new Ethernet device specified by arguments.
634 * A pointer to a strings array describing the new device
635 * to be attached. The strings should be a pci address like
636 * `0000:01:00.0` or **virtual** device name like `eth_pcap0`.
638 * A pointer to a port identifier actually attached.
641 * 0 on success and port_id is filled, negative on error.
643 int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
645 * Doxygen supports Markdown style syntax such as bold, italics, fixed width text and lists.
646 For example the second line in the ``devargs`` parameter in the previous example will be rendered as:
648 The strings should be a pci address like ``0000:01:00.0`` or **virtual** device name like ``eth_pcap0``.
650 * Use ``-`` instead of ``*`` for lists within the Doxygen comment since the latter can get confused with the comment delimiter.
652 * Add an empty line between the function description, the ``@params`` and ``@return`` for readability.
654 * Place the ``@params`` description on separate line and indent it by 2 spaces.
655 (It would be better to use no indentation since this is more common and also because checkpatch complains about leading
656 whitespace in comments.
657 However this is the convention used in the existing DPDK code.)
659 * Documented functions can be linked to simply by adding ``()`` to the function name:
664 * The functions exported by the application Ethernet API to setup
665 * a device designated by its port identifier must be invoked in
666 * the following order:
667 * - rte_eth_dev_configure()
668 * - rte_eth_tx_queue_setup()
669 * - rte_eth_rx_queue_setup()
670 * - rte_eth_dev_start()
673 In the API documentation the functions will be rendered as links, see the
674 `online section of the rte_ethdev.h docs <http://dpdk.org/doc/api/rte__ethdev_8h.html>`_ that contains the above text.
676 * The ``@see`` keyword can be used to create a *see also* link to another file or library.
677 This directive should be placed on one line at the bottom of the documentation section.
684 * Some text that references mempools.
689 * Doxygen supports two types of comments for documenting variables, constants and members: prefix and postfix:
693 /** This is a prefix comment. */
694 #define RTE_FOO_ERROR 0x023.
696 #define RTE_BAR_ERROR 0x024. /**< This is a postfix comment. */
698 * Postfix comments are preferred for struct members and constants if they can be documented in the same way:
702 struct rte_eth_stats {
703 uint64_t ipackets; /**< Total number of received packets. */
704 uint64_t opackets; /**< Total number of transmitted packets.*/
705 uint64_t ibytes; /**< Total number of received bytes. */
706 uint64_t obytes; /**< Total number of transmitted bytes. */
707 uint64_t imissed; /**< Total of RX missed packets. */
708 uint64_t ibadcrc; /**< Total of RX packets with CRC error. */
709 uint64_t ibadlen; /**< Total of RX packets with bad length. */
712 Note: postfix comments should be aligned with spaces not tabs in accordance
713 with the :ref:`coding_style`.
715 * If a single comment type can't be used, due to line length limitations then
716 prefix comments should be preferred.
717 For example this section of the code contains prefix comments, postfix comments on the same line and postfix
718 comments on a separate line:
722 /** Number of elements in the elt_pa array. */
723 uint32_t pg_num __rte_cache_aligned;
724 uint32_t pg_shift; /**< LOG2 of the physical pages. */
725 uintptr_t pg_mask; /**< Physical page mask value. */
726 uintptr_t elt_va_start;
727 /**< Virtual address of the first mempool object. */
728 uintptr_t elt_va_end;
729 /**< Virtual address of the <size + 1> mempool object. */
730 phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];
731 /**< Array of physical page addresses for the mempool buffer. */
733 This doesn't have an effect on the rendered documentation but it is confusing for the developer reading the code.
734 It this case it would be clearer to use prefix comments throughout:
738 /** Number of elements in the elt_pa array. */
739 uint32_t pg_num __rte_cache_aligned;
740 /** LOG2 of the physical pages. */
742 /** Physical page mask value. */
744 /** Virtual address of the first mempool object. */
745 uintptr_t elt_va_start;
746 /** Virtual address of the <size + 1> mempool object. */
747 uintptr_t elt_va_end;
748 /** Array of physical page addresses for the mempool buffer. */
749 phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];
751 * Check for Doxygen warnings in new code by checking the API documentation build::
753 make doc-api-html >/dev/null
755 * Read the rendered section of the documentation that you have added for correctness, clarity and consistency
756 with the surrounding text.