+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
.. _doc_guidelines:
DPDK Documentation Guidelines
This document outlines the guidelines for writing the DPDK Guides and API documentation in RST and Doxygen format.
-It also explains the structure of the DPDK documentation and shows how to build the Html and PDF versions of the documents.
+It also explains the structure of the DPDK documentation and how to build it.
Structure of the Documentation
The main directories that contain files related to documentation are shown below::
lib
- |-- librte_acl
- |-- librte_cfgfile
- |-- librte_cmdline
- |-- librte_compat
- |-- librte_eal
+ |-- acl
+ |-- cfgfile
+ |-- cmdline
+ |-- eal
| |-- ...
...
doc
|-- testpmd_app_ug
|-- rel_notes
|-- nics
- |-- xen
|-- ...
-The API documentation is built from `Doxygen <http://www.stack.nl/~dimitri/doxygen/>`_ comments in the header files.
-These files are mainly in the ``lib/librte_*`` directories although some of the Poll Mode Drivers in ``drivers/net``
+The API documentation is built from `Doxygen <http://www.doxygen.nl>`_ comments in the header files.
+These files are mainly in the ``lib/*`` directories although some of the Poll Mode Drivers in ``drivers/net``
are also documented with Doxygen.
The configuration files that are used to control the Doxygen output are in the ``doc/api`` directory.
The user guides such as *The Programmers Guide* and the *FreeBSD* and *Linux Getting Started* Guides are generated
-from RST markup text files using the `Sphinx <http://sphinx-doc.org/index.html>`_ Documentation Generator.
+from RST markup text files using the `Sphinx <http://sphinx-doc.org>`_ Documentation Generator.
These files are included in the ``doc/guides/`` directory.
The output is controlled by the ``doc/guides/conf.py`` file.
The Release Notes document which features have been added in the current and previous releases of DPDK and highlight
any known issues.
- The Releases Notes also contain notifications of features that will change ABI compatibility in the next major release.
+ The Releases Notes also contain notifications of features that will change ABI compatibility in the next release.
Developers should include updates to the Release Notes with patch sets that relate to any of the following sections:
* **API documentation**
The API documentation explains how to use the public DPDK functions.
- The `API index page <http://dpdk.org/doc/api/>`_ shows the generated API documentation with related groups of functions.
+ The `API index page <https://doc.dpdk.org/api/>`_ shows the generated API documentation with related groups of functions.
The API documentation should be updated via Doxygen comments when new functions are added.
Dependencies
~~~~~~~~~~~~
-
The following dependencies must be installed to build the documentation:
* Doxygen.
-
* Sphinx (also called python-sphinx).
-* TexLive (at least TexLive-core and the extra Latex support).
-
-* Inkscape.
-
`Doxygen`_ generates documentation from commented source code.
It can be installed as follows:
# Red Hat/Fedora.
sudo dnf -y install doxygen
-`Sphinx`_ is a Python documentation tool for converting RST files to Html or to PDF (via LaTeX).
+`Sphinx`_ is a Python documentation tool for converting RST files to HTML.
For full support with figure and table captioning the latest version of Sphinx can be installed as follows:
.. code-block:: console
# Ubuntu/Debian.
- sudo apt-get -y install python-pip
- sudo pip install --upgrade sphinx
- sudo pip install --upgrade sphinx_rtd_theme
+ sudo apt-get -y install python3-sphinx python3-sphinx-rtd-theme
# Red Hat/Fedora.
- sudo dnf -y install python-pip
- sudo pip install --upgrade sphinx
- sudo pip install --upgrade sphinx_rtd_theme
+ sudo dnf -y install python3-sphinx python3-sphinx_rtd_theme
-For further information on getting started with Sphinx see the `Sphinx Tutorial <http://sphinx-doc.org/tutorial.html>`_.
+For further information on getting started with Sphinx see the
+`Sphinx Getting Started <http://www.sphinx-doc.org/en/master/usage/quickstart.html>`_.
.. Note::
To get full support for Figure and Table numbering it is best to install Sphinx 1.3.1 or later.
-`Inkscape`_ is a vector based graphics program which is used to create SVG images and also to convert SVG images to PDF images.
-It can be installed as follows:
-
-.. code-block:: console
-
- # Ubuntu/Debian.
- sudo apt-get -y install inkscape
-
- # Red Hat/Fedora.
- sudo dnf -y install inkscape
-
-`TexLive <http://www.tug.org/texlive/>`_ is an installation package for Tex/LaTeX.
-It is used to generate the PDF versions of the documentation.
-The main required packages can be installed as follows:
-
-.. code-block:: console
-
- # Ubuntu/Debian.
- sudo apt-get -y install texlive-latex-extra
-
- # Red Hat/Fedora, selective install.
- sudo dnf -y install texlive-collection-latexextra
-
-
Build commands
~~~~~~~~~~~~~~
The documentation is built using the standard DPDK build system.
-Some examples are shown below:
-
-* Generate all the documentation targets::
-
- make doc
-
-* Generate the Doxygen API documentation in Html::
-
- make doc-api-html
-
-* Generate the guides documentation in Html::
-
- make doc-guides-html
-
-* Generate the guides documentation in Pdf::
- make doc-guides-pdf
+To build the documentation::
-The output of these commands is generated in the ``build`` directory::
+ ninja -C build doc
- build/doc
- |-- html
- | |-- api
- | +-- guides
- |
- +-- pdf
- +-- guides
+See :doc:`../linux_gsg/build_dpdk` for more detail on compiling DPDK with meson.
+The output is generated in the directories ``build/doc/html/{api,guides}``.
.. Note::
Make sure to fix any Sphinx or Doxygen warnings when adding or updating documentation.
-The documentation output files can be removed as follows::
-
- make doc-clean
-
Document Guidelines
-------------------
RST Guidelines
--------------
-The RST (reStructuredText) format is a plain text markup format that can be converted to Html, PDF or other formats.
+The RST (reStructuredText) format is a plain text markup format
+that can be converted to HTML or other formats.
It is most closely associated with Python but it can be used to document any language.
It is used in DPDK to document everything apart from the API.
Line Length
~~~~~~~~~~~
-* The recommended style for the DPDK documentation is to put sentences on separate lines.
- This allows for easier reviewing of patches.
- Multiple sentences which are not separated by a blank line are joined automatically into paragraphs, for example::
-
- Here is an example sentence.
- Long sentences over the limit shown below can be wrapped onto
- a new line.
- These three sentences will be joined into the same paragraph.
-
- This is a new paragraph, since it is separated from the
- previous paragraph by a blank line.
-
- This would be rendered as follows:
-
- *Here is an example sentence.
- Long sentences over the limit shown below can be wrapped onto
- a new line.
- These three sentences will be joined into the same paragraph.*
-
- *This is a new paragraph, since it is separated from the
- previous paragraph by a blank line.*
+* Lines in sentences should be less than 80 characters and wrapped at
+ words. Multiple sentences which are not separated by a blank line are joined
+ automatically into paragraphs.
+* Lines in literal blocks should be less than 80 characters
+ since they are not wrapped by the document formatters.
-* Long sentences should be wrapped at 120 characters +/- 10 characters. They should be wrapped at words.
+ Long literal command lines can be shown wrapped with backslashes. For
+ example::
-* Lines in literal blocks must by less than 80 characters since they aren't wrapped by the document formatters
- and can exceed the page width in PDF documents.
+ dpdk-testpmd -l 2-3 -n 4 \
+ --vdev=virtio_user0,path=/dev/vhost-net,queues=2,queue_size=1024 \
+ -- -i --tx-offloads=0x0000002c --enable-lro --txq=2 --rxq=2 \
+ --txd=1024 --rxd=1024
Whitespace
return 0;
}
+* Code snippets can also be included directly from the code using the ``literalinclude`` block.
+ Using this block instead of a code block will ensure that the code snippets
+ shown in the documentation are always up to date with the code.
+
+ The following will include a snippet from the skeleton sample app::
+
+ .. literalinclude:: ../../../examples/skeleton/basicfwd.c
+ :language: c
+ :start-after: Display the port MAC address.
+ :end-before: Enable RX in promiscuous mode for the Ethernet device.
+ :dedent: 1
+
+ This would be rendered as:
+
+ .. literalinclude:: ../../../examples/skeleton/basicfwd.c
+ :language: c
+ :start-after: Display the port MAC address.
+ :end-before: Enable RX in promiscuous mode for the Ethernet device.
+ :dedent: 1
+
+ Specifying ``:language:`` will enable syntax highlighting for the specified language.
+ ``:dedent:`` is used in this example to remove 1 leading tab from each line of the snippet.
+
+* ``start-after`` and ``end-before`` can use any text within a given file,
+ however it may be difficult to find unique text within your code to mark the
+ start and end of your snippets. In these cases, it is recommended to include
+ explicit tags in your code to denote these locations for documentation purposes.
+ The accepted format for these comments is:
+
+ * Before the code snippet, create a new comment which is a sentence explaining
+ what the code snippet contains. The comment is terminated with a scissors ``8<``.
+ * After the code snippet, create another new comment which starts with a
+ scissors ``>8``, then ``End of`` and the first comment repeated.
+ * The scissors should be orientated as shown to make it clear what code is being snipped.
+
+ This can be done as follows:
+
+ .. code-block:: c
+
+ /* Example feature being documented. 8< */
+ foo(bar);
+ /* >8 End of example feature being documented. */
+
+ ``foo(bar);`` could then be included in the docs using::
+
+ .. literalinclude:: ../../../examples/sample_app/main.c
+ :language: c
+ :start-after: Example feature being documented. 8<
+ :end-before: >8 End of example feature being documented.
+
+ If a multiline comment is needed before the snippet,
+ then the last line of the multiline comment should be in the same format as
+ the first comment shown in the example.
+
+* More information about the ``literalinclude`` block can be found within the
+ `Sphinx Documentation <https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html?highlight=literalinclude#directive-literalinclude>`_.
* The default encoding for a literal block using the simplified ``::``
directive is ``none``.
-* Lines in literal blocks must be less than 80 characters since they can exceed the page width when converted to PDF documentation.
- For long literal lines that exceed that limit try to wrap the text at sensible locations.
+* Lines in literal blocks should be less than 80 characters.
+ For long literal lines, try to wrap the text at sensible locations.
For example a long command line could be documented like this and still work if copied directly from the docs::
- build/app/testpmd -c7 -n3 --vdev=net_pcap0,iface=eth0 \
+ ./<build_dir>/app/dpdk-testpmd -l 0-2 -n3 --vdev=net_pcap0,iface=eth0 \
--vdev=net_pcap1,iface=eth1 \
-- -i --nb-cores=2 --nb-ports=2 \
--total-num-mbufs=2048
~~~~~~
* RST tables should be used sparingly.
- They are hard to format and to edit, they are often rendered incorrectly in PDF format, and the same information
+ They are hard to format and to edit, and the same information
can usually be shown just as clearly with a definition or bullet list.
* Tables in the documentation should be formatted as follows:
The QOS configuration is shown in :numref:`table_qos_pipes`.
-* Tables should not include merged cells since they are not supported by the PDF renderer.
-
.. _links:
~~~~~~~~~~
* Links to external websites can be plain URLs.
- The following is rendered as http://dpdk.org::
+ The following is rendered as https://dpdk.org::
- http://dpdk.org
+ https://dpdk.org
* They can contain alternative text.
- The following is rendered as `Check out DPDK <http://dpdk.org>`_::
+ The following is rendered as `Check out DPDK <https://dpdk.org>`_::
- `Check out DPDK <http://dpdk.org>`_
+ `Check out DPDK <https://dpdk.org>`_
* An internal link can be generated by placing labels in the document with the format ``.. _label_name``.
The DPDK API is documented using Doxygen comment annotations in the header files.
Doxygen is a very powerful tool, it is extremely configurable and with a little effort can be used to create expressive documents.
-See the `Doxygen website <http://www.stack.nl/~dimitri/doxygen/>`_ for full details on how to use it.
+See the `Doxygen website <http://www.doxygen.nl>`_ for full details on how to use it.
The following are some guidelines for use of Doxygen in the DPDK API documentation:
.. code-block:: c
/**
- * Attach a new Ethernet device specified by arguments.
- *
- * @param devargs
- * A pointer to a strings array describing the new device
- * to be attached. The strings should be a pci address like
- * `0000:01:00.0` or **virtual** device name like `net_pcap0`.
- * @param port_id
- * A pointer to a port identifier actually attached.
+ * Try to take the lock.
*
+ * @param sl
+ * A pointer to the spinlock.
* @return
- * 0 on success and port_id is filled, negative on error.
+ * 1 if the lock is successfully taken; 0 otherwise.
*/
- int rte_eth_dev_attach(const char *devargs, uint8_t *port_id);
+ int rte_spinlock_trylock(rte_spinlock_t *sl);
* Doxygen supports Markdown style syntax such as bold, italics, fixed width text and lists.
For example the second line in the ``devargs`` parameter in the previous example will be rendered as:
*/
In the API documentation the functions will be rendered as links, see the
- `online section of the rte_ethdev.h docs <http://dpdk.org/doc/api/rte__ethdev_8h.html>`_ that contains the above text.
+ `online section of the rte_ethdev.h docs <https://doc.dpdk.org/api/rte__ethdev_8h.html>`_ that contains the above text.
* The ``@see`` keyword can be used to create a *see also* link to another file or library.
This directive should be placed on one line at the bottom of the documentation section.
/** Array of physical page addresses for the mempool buffer. */
phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];
-* Check for Doxygen warnings in new code by checking the API documentation build::
-
- make doc-api-html >/dev/null
-
* Read the rendered section of the documentation that you have added for correctness, clarity and consistency
with the surrounding text.
git.droids-corp.org / dpdk.git / blobdiff