Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/76433/?format=api
{ "id": 76433, "url": "http://patches.dpdk.org/api/patches/76433/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/patch/20200903152717.42095-23-ciara.power@intel.com/", "project": { "id": 1, "url": "http://patches.dpdk.org/api/projects/1/?format=api", "name": "DPDK", "link_name": "dpdk", "list_id": "dev.dpdk.org", "list_email": "dev@dpdk.org", "web_url": "http://core.dpdk.org", "scm_url": "git://dpdk.org/dpdk", "webscm_url": "http://git.dpdk.org/dpdk", "list_archive_url": "https://inbox.dpdk.org/dev", "list_archive_url_format": "https://inbox.dpdk.org/dev/{}", "commit_url_format": "" }, "msgid": "<20200903152717.42095-23-ciara.power@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/20200903152717.42095-23-ciara.power@intel.com", "date": "2020-09-03T15:27:02", "name": "[v3,22/37] doc: remove references to make in contributing guides", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": true, "hash": "f6bb2ff48220a10f2fe4bd6efb2cd55b2df12856", "submitter": { "id": 978, "url": "http://patches.dpdk.org/api/people/978/?format=api", "name": "Power, Ciara", "email": "ciara.power@intel.com" }, "delegate": { "id": 1, "url": "http://patches.dpdk.org/api/users/1/?format=api", "username": "tmonjalo", "first_name": "Thomas", "last_name": "Monjalon", "email": "thomas@monjalon.net" }, "mbox": "http://patches.dpdk.org/project/dpdk/patch/20200903152717.42095-23-ciara.power@intel.com/mbox/", "series": [ { "id": 11929, "url": "http://patches.dpdk.org/api/series/11929/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=11929", "date": "2020-09-03T15:26:40", "name": "remove make support in DPDK", "version": 3, "mbox": "http://patches.dpdk.org/series/11929/mbox/" } ], "comments": "http://patches.dpdk.org/api/patches/76433/comments/", "check": "success", "checks": "http://patches.dpdk.org/api/patches/76433/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 3D247A04BF;\n\tThu, 3 Sep 2020 17:34:02 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 9A16E1C1D8;\n\tThu, 3 Sep 2020 17:29:02 +0200 (CEST)", "from mga18.intel.com (mga18.intel.com [134.134.136.126])\n by dpdk.org (Postfix) with ESMTP id AD3FC1C1D0\n for <dev@dpdk.org>; Thu, 3 Sep 2020 17:29:00 +0200 (CEST)", "from orsmga006.jf.intel.com ([10.7.209.51])\n by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 03 Sep 2020 08:29:00 -0700", "from silpixa00399953.ir.intel.com (HELO\n silpixa00399953.ger.corp.intel.com) ([10.237.222.53])\n by orsmga006.jf.intel.com with ESMTP; 03 Sep 2020 08:28:58 -0700" ], "IronPort-SDR": [ "\n 1Lh7JHbMj437XuZNqRFk2dUZXFJkjmqRF1VBYtCn9Lyz/Cejt92+X0rjOGTqNmD6yWhy+xaH4y\n 1FrVsf/jwh8Q==", "\n L0d8yftMxj3+ygp+XggHqcNyNgEaoEO+2Uy3zUM4hD7lZkWeQwXOMyKex1W6NNyhlV99QeMA7Z\n Q5V/+7WAvH6A==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9733\"; a=\"145290730\"", "E=Sophos;i=\"5.76,387,1592895600\"; d=\"scan'208\";a=\"145290730\"", "E=Sophos;i=\"5.76,387,1592895600\"; d=\"scan'208\";a=\"302244046\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "From": "Ciara Power <ciara.power@intel.com>", "To": "dev@dpdk.org", "Cc": "Ciara Power <ciara.power@intel.com>,\n Louise Kilheeney <louise.kilheeney@intel.com>,\n John McNamara <john.mcnamara@intel.com>,\n Marko Kovacevic <marko.kovacevic@intel.com>", "Date": "Thu, 3 Sep 2020 16:27:02 +0100", "Message-Id": "<20200903152717.42095-23-ciara.power@intel.com>", "X-Mailer": "git-send-email 2.17.1", "In-Reply-To": "<20200903152717.42095-1-ciara.power@intel.com>", "References": "<20200807123009.21266-1-ciara.power@intel.com>\n <20200903152717.42095-1-ciara.power@intel.com>", "Subject": "[dpdk-dev] [PATCH v3 22/37] doc: remove references to make in\n\tcontributing guides", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "content": "Make is no longer supported for compiling DPDK, references are now\nremoved in the documentation.\n\nSigned-off-by: Ciara Power <ciara.power@intel.com>\nSigned-off-by: Louise Kilheeney <louise.kilheeney@intel.com>\n---\n doc/guides/contributing/coding_style.rst | 46 +-------\n doc/guides/contributing/design.rst | 127 ++--------------------\n doc/guides/contributing/documentation.rst | 31 +-----\n doc/guides/contributing/patches.rst | 45 --------\n 4 files changed, 18 insertions(+), 231 deletions(-)", "diff": "diff --git a/doc/guides/contributing/coding_style.rst b/doc/guides/contributing/coding_style.rst\nindex b55075eaa2..dc352d03ca 100644\n--- a/doc/guides/contributing/coding_style.rst\n+++ b/doc/guides/contributing/coding_style.rst\n@@ -773,52 +773,16 @@ The ``pep8`` tool can be used for testing compliance with the guidelines.\n Integrating with the Build System\n ---------------------------------\n \n-DPDK supports being built in two different ways:\n-\n-* using ``make`` - or more specifically \"GNU make\", i.e. ``gmake`` on FreeBSD\n-* using the tools ``meson`` and ``ninja``\n+DPDK supports being built by using the tools ``meson`` and ``ninja``\n \n Any new library or driver to be integrated into DPDK should support being\n-built with both systems. While building using ``make`` is a legacy approach, and\n-most build-system enhancements are being done using ``meson`` and ``ninja``\n-there are no plans at this time to deprecate the legacy ``make`` build system.\n+built with this system.\n \n-Therefore all new component additions should include both a ``Makefile`` and a\n-``meson.build`` file, and should be added to the component lists in both the\n-``Makefile`` and ``meson.build`` files in the relevant top-level directory:\n+Therefore all new component additions should include a ``meson.build`` file,\n+and should be added to the component lists in the ``meson.build`` files in the\n+relevant top-level directory:\n either ``lib`` directory or a ``driver`` subdirectory.\n \n-Makefile Contents\n-~~~~~~~~~~~~~~~~~\n-\n-The ``Makefile`` for the component should be of the following format, where\n-``<name>`` corresponds to the name of the library in question, e.g. hash,\n-lpm, etc. For drivers, the same format of Makefile is used.\n-\n-.. code-block:: none\n-\n-\t# pull in basic DPDK definitions, including whether library is to be\n-\t# built or not\n-\tinclude $(RTE_SDK)/mk/rte.vars.mk\n-\n-\t# library name\n-\tLIB = librte_<name>.a\n-\n-\t# any library cflags needed. Generally add \"-O3 $(WERROR_FLAGS)\"\n-\tCFLAGS += -O3\n-\tCFLAGS += $(WERROR_FLAGS)\n-\n-\t# the symbol version information for the library\n-\tEXPORT_MAP := rte_<name>_version.map\n-\n-\t# all source filenames are stored in SRCS-y\n-\tSRCS-$(CONFIG_RTE_LIBRTE_<NAME>) += rte_<name>.c\n-\n-\t# install includes\n-\tSYMLINK-$(CONFIG_RTE_LIBRTE_<NAME>)-include += rte_<name>.h\n-\n-\t# pull in rules to build the library\n-\tinclude $(RTE_SDK)/mk/rte.lib.mk\n \n Meson Build File Contents - Libraries\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ndiff --git a/doc/guides/contributing/design.rst b/doc/guides/contributing/design.rst\nindex 5fe7f63942..6ce0de97ac 100644\n--- a/doc/guides/contributing/design.rst\n+++ b/doc/guides/contributing/design.rst\n@@ -21,7 +21,7 @@ A file located in a subdir of \"linux\" is specific to this execution environment.\n \n When absolutely necessary, there are several ways to handle specific code:\n \n-* Use a ``#ifdef`` with the CONFIG option in the C code.\n+* Use a ``#ifdef`` with a build definition macro in the C code.\n This can be done when the differences are small and they can be embedded in the same C file:\n \n .. code-block:: c\n@@ -32,30 +32,22 @@ When absolutely necessary, there are several ways to handle specific code:\n titi();\n #endif\n \n-* Use the CONFIG option in the Makefile. This is done when the differences are more significant.\n- In this case, the code is split into two separate files that are architecture or environment specific.\n- This should only apply inside the EAL library.\n-\n-.. note::\n-\n- As in the linux kernel, the ``CONFIG_`` prefix is not used in C code.\n- This is only needed in Makefiles or shell scripts.\n \n Per Architecture Sources\n ~~~~~~~~~~~~~~~~~~~~~~~~\n \n-The following config options can be used:\n+The following macro options can be used:\n \n-* ``CONFIG_RTE_ARCH`` is a string that contains the name of the architecture.\n-* ``CONFIG_RTE_ARCH_I686``, ``CONFIG_RTE_ARCH_X86_64``, ``CONFIG_RTE_ARCH_X86_64_32`` or ``CONFIG_RTE_ARCH_PPC_64`` are defined only if we are building for those architectures.\n+* ``RTE_ARCH`` is a string that contains the name of the architecture.\n+* ``RTE_ARCH_I686``, ``RTE_ARCH_X86_64``, ``RTE_ARCH_X86_64_32`` or ``RTE_ARCH_PPC_64`` are defined only if we are building for those architectures.\n \n Per Execution Environment Sources\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n \n-The following config options can be used:\n+The following macro options can be used:\n \n-* ``CONFIG_RTE_EXEC_ENV`` is a string that contains the name of the executive environment.\n-* ``CONFIG_RTE_EXEC_ENV_FREEBSD`` or ``CONFIG_RTE_EXEC_ENV_LINUX`` are defined only if we are building for this execution environment.\n+* ``RTE_EXEC_ENV`` is a string that contains the name of the executive environment.\n+* ``RTE_EXEC_ENV_FREEBSD`` or ``RTE_EXEC_ENV_LINUX`` are defined only if we are building for this execution environment.\n \n Mbuf features\n -------------\n@@ -73,111 +65,6 @@ Adding a new static field or flag must be an exception matching many criteria\n like (non exhaustive): wide usage, performance, size.\n \n \n-Library Statistics\n-------------------\n-\n-Description\n-~~~~~~~~~~~\n-\n-This document describes the guidelines for DPDK library-level statistics counter\n-support. This includes guidelines for turning library statistics on and off and\n-requirements for preventing ABI changes when implementing statistics.\n-\n-\n-Mechanism to allow the application to turn library statistics on and off\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-Each library that maintains statistics counters should provide a single build\n-time flag that decides whether the statistics counter collection is enabled or\n-not. This flag should be exposed as a variable within the DPDK configuration\n-file. When this flag is set, all the counters supported by current library are\n-collected for all the instances of every object type provided by the library.\n-When this flag is cleared, none of the counters supported by the current library\n-are collected for any instance of any object type provided by the library:\n-\n-.. code-block:: console\n-\n- # DPDK file config/common_linux, config/common_freebsd, etc.\n- CONFIG_RTE_<LIBRARY_NAME>_STATS_COLLECT=y/n\n-\n-The default value for this DPDK configuration file variable (either \"yes\" or\n-\"no\") is decided by each library.\n-\n-\n-Prevention of ABI changes due to library statistics support\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-The layout of data structures and prototype of functions that are part of the\n-library API should not be affected by whether the collection of statistics\n-counters is turned on or off for the current library. In practical terms, this\n-means that space should always be allocated in the API data structures for\n-statistics counters and the statistics related API functions are always built\n-into the code, regardless of whether the statistics counter collection is turned\n-on or off for the current library.\n-\n-When the collection of statistics counters for the current library is turned\n-off, the counters retrieved through the statistics related API functions should\n-have a default value of zero.\n-\n-\n-Motivation to allow the application to turn library statistics on and off\n-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n-\n-It is highly recommended that each library provides statistics counters to allow\n-an application to monitor the library-level run-time events. Typical counters\n-are: number of packets received/dropped/transmitted, number of buffers\n-allocated/freed, number of occurrences for specific events, etc.\n-\n-However, the resources consumed for library-level statistics counter collection\n-have to be spent out of the application budget and the counters collected by\n-some libraries might not be relevant to the current application. In order to\n-avoid any unwanted waste of resources and/or performance impacts, the\n-application should decide at build time whether the collection of library-level\n-statistics counters should be turned on or off for each library individually.\n-\n-Library-level statistics counters can be relevant or not for specific\n-applications:\n-\n-* For Application A, counters maintained by Library X are always relevant and\n- the application needs to use them to implement certain features, such as traffic\n- accounting, logging, application-level statistics, etc. In this case,\n- the application requires that collection of statistics counters for Library X is\n- always turned on.\n-\n-* For Application B, counters maintained by Library X are only useful during the\n- application debug stage and are not relevant once debug phase is over. In this\n- case, the application may decide to turn on the collection of Library X\n- statistics counters during the debug phase and at a later stage turn them off.\n-\n-* For Application C, counters maintained by Library X are not relevant at all.\n- It might be that the application maintains its own set of statistics counters\n- that monitor a different set of run-time events (e.g. number of connection\n- requests, number of active users, etc). It might also be that the application\n- uses multiple libraries (Library X, Library Y, etc) and it is interested in the\n- statistics counters of Library Y, but not in those of Library X. In this case,\n- the application may decide to turn the collection of statistics counters off for\n- Library X and on for Library Y.\n-\n-The statistics collection consumes a certain amount of CPU resources (cycles,\n-cache bandwidth, memory bandwidth, etc) that depends on:\n-\n-* Number of libraries used by the current application that have statistics\n- counters collection turned on.\n-\n-* Number of statistics counters maintained by each library per object type\n- instance (e.g. per port, table, pipeline, thread, etc).\n-\n-* Number of instances created for each object type supported by each library.\n-\n-* Complexity of the statistics logic collection for each counter: when only\n- some occurrences of a specific event are valid, additional logic is typically\n- needed to decide whether the current occurrence of the event should be counted\n- or not. For example, in the event of packet reception, when only TCP packets\n- with destination port within a certain range should be recorded, conditional\n- branches are usually required. When processing a burst of packets that have been\n- validated for header integrity, counting the number of bits set in a bitmask\n- might be needed.\n-\n PF and VF Considerations\n ------------------------\n \ndiff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst\nindex 375ea64ba8..768453126f 100644\n--- a/doc/guides/contributing/documentation.rst\n+++ b/doc/guides/contributing/documentation.rst\n@@ -222,25 +222,14 @@ Build commands\n ~~~~~~~~~~~~~~\n \n The documentation is built using the standard DPDK build system.\n-Some examples are shown below:\n \n-* Generate all the documentation targets::\n+To enable doc building::\n \n- make doc\n+ meson configure -Denable_docs=true\n \n-* Generate the Doxygen API documentation in Html::\n+See :doc:`../linux_gsg/build_dpdk` for more detail on compiling DPDK with meson.\n \n- make doc-api-html\n-\n-* Generate the guides documentation in Html::\n-\n- make doc-guides-html\n-\n-* Generate the guides documentation in Pdf::\n-\n- make doc-guides-pdf\n-\n-The output of these commands is generated in the ``build`` directory::\n+The output is generated in the ``build`` directory::\n \n build/doc\n |-- html\n@@ -255,10 +244,6 @@ The output of these commands is generated in the ``build`` directory::\n \n Make sure to fix any Sphinx or Doxygen warnings when adding or updating documentation.\n \n-The documentation output files can be removed as follows::\n-\n- make doc-clean\n-\n \n Document Guidelines\n -------------------\n@@ -308,7 +293,7 @@ Line Length\n Long literal command lines can be shown wrapped with backslashes. For\n example::\n \n- testpmd -l 2-3 -n 4 \\\n+ dpdk-testpmd -l 2-3 -n 4 \\\n --vdev=virtio_user0,path=/dev/vhost-net,queues=2,queue_size=1024 \\\n -- -i --tx-offloads=0x0000002c --enable-lro --txq=2 --rxq=2 \\\n --txd=1024 --rxd=1024\n@@ -460,7 +445,7 @@ Code and Literal block sections\n For long literal lines that exceed that limit try to wrap the text at sensible locations.\n For example a long command line could be documented like this and still work if copied directly from the docs::\n \n- build/app/testpmd -l 0-2 -n3 --vdev=net_pcap0,iface=eth0 \\\n+ ./<build_dir>/app/dpdk-testpmd -l 0-2 -n3 --vdev=net_pcap0,iface=eth0 \\\n --vdev=net_pcap1,iface=eth1 \\\n -- -i --nb-cores=2 --nb-ports=2 \\\n --total-num-mbufs=2048\n@@ -743,9 +728,5 @@ The following are some guidelines for use of Doxygen in the DPDK API documentati\n /** Array of physical page addresses for the mempool buffer. */\n phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];\n \n-* Check for Doxygen warnings in new code by checking the API documentation build::\n-\n- make doc-api-html >/dev/null\n-\n * Read the rendered section of the documentation that you have added for correctness, clarity and consistency\n with the surrounding text.\ndiff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst\nindex 425bb874f8..bafa95be59 100644\n--- a/doc/guides/contributing/patches.rst\n+++ b/doc/guides/contributing/patches.rst\n@@ -464,51 +464,6 @@ and the -r option allows the user specify a ``git log`` range.\n Checking Compilation\n --------------------\n \n-Makefile System\n-~~~~~~~~~~~~~~~\n-\n-Compilation of patches and changes should be tested using the ``test-build.sh`` script in the ``devtools``\n-directory of the DPDK repo::\n-\n- devtools/test-build.sh x86_64-native-linux-gcc+next+shared\n-\n-The script usage is::\n-\n- test-build.sh [-h] [-jX] [-s] [config1 [config2] ...]]\n-\n-Where:\n-\n-* ``-h``: help, usage.\n-* ``-jX``: use X parallel jobs in \"make\".\n-* ``-s``: short test with only first config and without examples/doc.\n-* ``config``: default config name plus config switches delimited with a ``+`` sign.\n-\n-Examples of configs are::\n-\n- x86_64-native-linux-gcc\n- x86_64-native-linux-gcc+next+shared\n- x86_64-native-linux-clang+shared\n-\n-The builds can be modified via the following environmental variables:\n-\n-* ``DPDK_BUILD_TEST_CONFIGS`` (target1+option1+option2 target2)\n-* ``DPDK_BUILD_TEST_DIR``\n-* ``DPDK_DEP_CFLAGS``\n-* ``DPDK_DEP_LDFLAGS``\n-* ``DPDK_DEP_PCAP`` (y/[n])\n-* ``DPDK_NOTIFY`` (notify-send)\n-\n-These can be set from the command line or in the config files shown above in the :ref:`contrib_checkpatch`.\n-\n-The recommended configurations and options to test compilation prior to submitting patches are::\n-\n- x86_64-native-linux-gcc+shared+next\n- x86_64-native-linux-clang+shared\n- i686-native-linux-gcc\n-\n- export DPDK_DEP_ZLIB=y\n- export DPDK_DEP_PCAP=y\n- export DPDK_DEP_SSL=y\n \n Meson System\n ~~~~~~~~~~~~\n", "prefixes": [ "v3", "22/37" ] }