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