Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/77484/?format=api
{ "id": 77484, "url": "http://patches.dpdk.org/api/patches/77484/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/patch/1599851920-16802-2-git-send-email-timothy.mcdaniel@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": "<1599851920-16802-2-git-send-email-timothy.mcdaniel@intel.com>", "list_archive_url": "https://inbox.dpdk.org/dev/1599851920-16802-2-git-send-email-timothy.mcdaniel@intel.com", "date": "2020-09-11T19:18:19", "name": "[v4,01/22] event/dlb: add documentation and meson infrastructure", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": true, "hash": "9de879939d30aca1e3f2a552a97e2d7da44b53a8", "submitter": { "id": 826, "url": "http://patches.dpdk.org/api/people/826/?format=api", "name": "Timothy McDaniel", "email": "timothy.mcdaniel@intel.com" }, "delegate": { "id": 310, "url": "http://patches.dpdk.org/api/users/310/?format=api", "username": "jerin", "first_name": "Jerin", "last_name": "Jacob", "email": "jerinj@marvell.com" }, "mbox": "http://patches.dpdk.org/project/dpdk/patch/1599851920-16802-2-git-send-email-timothy.mcdaniel@intel.com/mbox/", "series": [ { "id": 12163, "url": "http://patches.dpdk.org/api/series/12163/?format=api", "web_url": "http://patches.dpdk.org/project/dpdk/list/?series=12163", "date": "2020-09-11T19:18:18", "name": "Add DLB PMD", "version": 4, "mbox": "http://patches.dpdk.org/series/12163/mbox/" } ], "comments": "http://patches.dpdk.org/api/patches/77484/comments/", "check": "fail", "checks": "http://patches.dpdk.org/api/patches/77484/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 9BA89A04C1;\n\tFri, 11 Sep 2020 21:22:12 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 0AE3F1C131;\n\tFri, 11 Sep 2020 21:22:08 +0200 (CEST)", "from mga12.intel.com (mga12.intel.com [192.55.52.136])\n by dpdk.org (Postfix) with ESMTP id D42181C120\n for <dev@dpdk.org>; Fri, 11 Sep 2020 21:22:04 +0200 (CEST)", "from fmsmga005.fm.intel.com ([10.253.24.32])\n by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 11 Sep 2020 12:22:04 -0700", "from txasoft-yocto.an.intel.com ([10.123.72.192])\n by fmsmga005.fm.intel.com with ESMTP; 11 Sep 2020 12:22:03 -0700" ], "IronPort-SDR": [ "\n JMiw/UI28c1C3FVCquZOEJU+GRtPJoQn+no/ZdrZLyUDGI/Q9Lm15e00rnrgxtY0oC3SuQijLG\n iO2GVNGPU2Vw==", "\n JN9MolaJdlc4udDo5mGPiWOLZEHNLeZkNKKjOhr6i+6nX8aJYHwpM7vwchfLOX2BQ2+3O9+9oZ\n 8mF8PLaNqREQ==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9741\"; a=\"138352250\"", "E=Sophos;i=\"5.76,416,1592895600\"; d=\"scan'208\";a=\"138352250\"", "E=Sophos;i=\"5.76,416,1592895600\"; d=\"scan'208\";a=\"506375633\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "From": "Timothy McDaniel <timothy.mcdaniel@intel.com>", "To": "Bruce Richardson <bruce.richardson@intel.com>,\n John McNamara <john.mcnamara@intel.com>,\n Marko Kovacevic <marko.kovacevic@intel.com>, Ray Kinsella <mdr@ashroe.eu>,\n Neil Horman <nhorman@tuxdriver.com>", "Cc": "dev@dpdk.org, erik.g.carrillo@intel.com, gage.eads@intel.com,\n harry.van.haaren@intel.com, jerinj@marvell.com", "Date": "Fri, 11 Sep 2020 14:18:19 -0500", "Message-Id": "<1599851920-16802-2-git-send-email-timothy.mcdaniel@intel.com>", "X-Mailer": "git-send-email 1.7.10", "In-Reply-To": "<1599851920-16802-1-git-send-email-timothy.mcdaniel@intel.com>", "References": "<1599851920-16802-1-git-send-email-timothy.mcdaniel@intel.com>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=UTF-8", "Content-Transfer-Encoding": "8bit", "Subject": "[dpdk-dev] =?utf-8?q?=5BPATCH_v4_01/22=5D_event/dlb=3A_add_document?=\n\t=?utf-8?q?ation_and_meson_infrastructure?=", "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": "Increased RTE_EVENT_MAX_QUEUES_PER_DEV config option\nfrom 64 to 255.\n\nNote that config/rte_config.h contains several configuration\nswitches, providing for fine control of the PMD's\nruntime behaviour.\n\nThe meson infrastructure is expanded as additional files are\nadded to this patchset.\n\nSigned-off-by: Timothy McDaniel <timothy.mcdaniel@intel.com>\n---\n config/rte_config.h | 8 +-\n doc/guides/eventdevs/dlb.rst | 340 ++++++++++++++++++++++++\n drivers/event/dlb/meson.build | 7 +\n drivers/event/dlb/rte_pmd_dlb_event_version.map | 3 +\n drivers/event/meson.build | 4 +\n 5 files changed, 361 insertions(+), 1 deletion(-)\n create mode 100644 doc/guides/eventdevs/dlb.rst\n create mode 100644 drivers/event/dlb/meson.build\n create mode 100644 drivers/event/dlb/rte_pmd_dlb_event_version.map", "diff": "diff --git a/config/rte_config.h b/config/rte_config.h\nindex 0bae630..4262339 100644\n--- a/config/rte_config.h\n+++ b/config/rte_config.h\n@@ -70,7 +70,7 @@\n \n /* eventdev defines */\n #define RTE_EVENT_MAX_DEVS 16\n-#define RTE_EVENT_MAX_QUEUES_PER_DEV 64\n+#define RTE_EVENT_MAX_QUEUES_PER_DEV 255\n #define RTE_EVENT_TIMER_ADAPTER_NUM_MAX 32\n #define RTE_EVENT_ETH_INTR_RING_SIZE 1024\n #define RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE 32\n@@ -131,4 +131,10 @@\n /* QEDE PMD defines */\n #define RTE_LIBRTE_QEDE_FW \"\"\n \n+/* DLB PMD defines */\n+#define RTE_LIBRTE_PMD_DLB_POLL_INTERVAL 1000\n+#define RTE_LIBRTE_PMD_DLB_UMWAIT_CTL_STATE 0\n+#undef RTE_LIBRTE_PMD_DLB_QUELL_STATS\n+#define RTE_LIBRTE_PMD_DLB_SW_CREDIT_QUANTA 32\n+\n #endif /* _RTE_CONFIG_H_ */\ndiff --git a/doc/guides/eventdevs/dlb.rst b/doc/guides/eventdevs/dlb.rst\nnew file mode 100644\nindex 0000000..e5759c0\n--- /dev/null\n+++ b/doc/guides/eventdevs/dlb.rst\n@@ -0,0 +1,340 @@\n+.. SPDX-License-Identifier: BSD-3-Clause\n+ Copyright(c) 2020 Intel Corporation.\n+\n+Driver for the Intel® Dynamic Load Balancer (DLB)\n+==================================================\n+\n+The DPDK dlb poll mode driver supports the Intel® Dynamic Load Balancer.\n+\n+Prerequisites\n+-------------\n+\n+- Follow the DPDK :ref:`Getting Started Guide for Linux <linux_gsg>` to setup\n+ the basic DPDK environment.\n+\n+Configuration\n+-------------\n+\n+* The DLB PF PMD is a user-space PMD that uses VFIO to gain direct\n+ device access. To use this operation mode, the PCIe PF device must be bound\n+ to a DPDK-compatible VFIO driver, such as vfio-pci.\n+\n+Eventdev API Notes\n+------------------\n+\n+The DLB provides the functions of a DPDK event device; specifically, it\n+supports atomic, ordered, and parallel scheduling events from queues to ports.\n+However, the DLB hardware is not a perfect match to the eventdev API. Some DLB\n+features are abstracted by the PMD (e.g. directed ports), some are only\n+accessible as vdev command-line parameters, and certain eventdev features are\n+not supported (e.g. the event flow ID is not maintained during scheduling).\n+\n+In general the dlb PMD is designed for ease-of-use and does not require a\n+detailed understanding of the hardware, but these details are important when\n+writing high-performance code. This section describes the places where the\n+eventdev API and DLB misalign.\n+\n+Scheduling Domain Configuration\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+There are 32 scheduling domainis the DLB.\n+When one is configured, it allocates load-balanced and\n+directed queues, ports, credits, and other hardware resources. Some\n+resource allocations are user-controlled -- the number of queues, for example\n+-- and others, like credit pools (one directed and one load-balanced pool per\n+scheduling domain), are not.\n+\n+The DLB is a closed system eventdev, and as such the ``nb_events_limit`` device\n+setup argument and the per-port ``new_event_threshold`` argument apply as\n+defined in the eventdev header file. The limit is applied to all enqueues,\n+regardless of whether it will consume a directed or load-balanced credit.\n+\n+Load-balanced and Directed Ports\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+DLB ports come in two flavors: load-balanced and directed. The eventdev API\n+does not have the same concept, but it has a similar one: ports and queues that\n+are singly-linked (i.e. linked to a single queue or port, respectively).\n+\n+The ``rte_event_dev_info_get()`` function reports the number of available\n+event ports and queues (among other things). For the DLB PMD, max_event_ports\n+and max_event_queues report the number of available load-balanced ports and\n+queues, and max_single_link_event_port_queue_pairs reports the number of\n+available directed ports and queues.\n+\n+When a scheduling domain is created in ``rte_event_dev_configure()``, the user\n+specifies ``nb_event_ports`` and ``nb_single_link_event_port_queues``, which\n+control the total number of ports (load-balanced and directed) and the number\n+of directed ports. Hence, the number of requested load-balanced ports is\n+``nb_event_ports - nb_single_link_event_ports``. The ``nb_event_queues`` field\n+specifies the total number of queues (load-balanced and directed). The number\n+of directed queues comes from ``nb_single_link_event_port_queues``, since\n+directed ports and queues come in pairs.\n+\n+When a port is setup, the ``RTE_EVENT_PORT_CFG_SINGLE_LINK`` flag determines\n+whether it should be configured as a directed (the flag is set) or a\n+load-balanced (the flag is unset) port. Similarly, the\n+``RTE_EVENT_QUEUE_CFG_SINGLE_LINK`` queue configuration flag controls\n+whether it is a directed or load-balanced queue.\n+\n+Load-balanced ports can only be linked to load-balanced queues, and directed\n+ports can only be linked to directed queues. Furthermore, directed ports can\n+only be linked to a single directed queue (and vice versa), and that link\n+cannot change after the eventdev is started.\n+\n+The eventdev API does not have a directed scheduling type. To support directed\n+traffic, the dlb PMD detects when an event is being sent to a directed queue\n+and overrides its scheduling type. Note that the originally selected scheduling\n+type (atomic, ordered, or parallel) is not preserved, and an event's sched_type\n+will be set to ``RTE_SCHED_TYPE_ATOMIC`` when it is dequeued from a directed\n+port.\n+\n+Flow ID\n+~~~~~~~\n+\n+The flow ID field is not preserved in the event when it is scheduled in the\n+DLB, because the DLB hardware control word format does not have sufficient\n+space to preserve every event field. As a result, the flow ID specified with\n+the enqueued event will not be in the dequeued event. If this field is\n+required, the application should pass it through an out-of-band path (for\n+example in the mbuf's udata64 field, if the event points to an mbuf) or\n+reconstruct the flow ID after receiving the event.\n+\n+Also, the DLB hardware control word supports a 16-bit flow ID. Since struct\n+rte_event's flow_id field is 20 bits, the DLB PMD drops the most significant\n+four bits from the event's flow ID.\n+\n+Hardware Credits\n+~~~~~~~~~~~~~~~~\n+\n+DLB uses a hardware credit scheme to prevent software from overflowing hardware\n+event storage, with each unit of storage represented by a credit. A port spends\n+a credit to enqueue an event, and hardware refills the ports with credits as the\n+events are scheduled to ports. Refills come from credit pools, and each port is\n+a member of a load-balanced credit pool and a directed credit pool. The\n+load-balanced credits are used to enqueue to load-balanced queues, and directed\n+credits are used for directed queues.\n+\n+A DLB eventdev contains one load-balanced and one directed credit pool. These\n+pools' sizes are controlled by the nb_events_limit field in struct\n+rte_event_dev_config. The load-balanced pool is sized to contain\n+nb_events_limit credits, and the directed pool is sized to contain\n+nb_events_limit/4 credits. The directed pool size can be overridden with the\n+num_dir_credits vdev argument, like so:\n+\n+ .. code-block:: console\n+\n+ --vdev=dlb1_event,num_dir_credits=<value>\n+\n+This can be used if the default allocation is too low or too high for the\n+specific application needs. The PMD also supports a vdev arg that limits the\n+max_num_events reported by rte_event_dev_info_get():\n+\n+ .. code-block:: console\n+\n+ --vdev=dlb1_event,max_num_events=<value>\n+\n+By default, max_num_events is reported as the total available load-balanced\n+credits. If multiple DLB-based applications are being used, it may be desirable\n+to control how many load-balanced credits each application uses, particularly\n+when application(s) are written to configure nb_events_limit equal to the\n+reported max_num_events.\n+\n+Each port is a member of both credit pools. A port's credit allocation is\n+defined by its low watermark, high watermark, and refill quanta. These three\n+parameters are calculated by the dlb PMD like so:\n+\n+- The load-balanced high watermark is set to the port's enqueue_depth.\n+ The directed high watermark is set to the minimum of the enqueue_depth and\n+ the directed pool size divided by the total number of ports.\n+- The refill quanta is set to half the high watermark.\n+- The low watermark is set to the minimum of 16 and the refill quanta.\n+\n+When the eventdev is started, each port is pre-allocated a high watermark's\n+worth of credits. For example, if an eventdev contains four ports with enqueue\n+depths of 32 and a load-balanced credit pool size of 4096, each port will start\n+with 32 load-balanced credits, and there will be 3968 credits available to\n+replenish the ports. Thus, a single port is not capable of enqueueing up to the\n+nb_events_limit (without any events being dequeued), since the other ports are\n+retaining their initial credit allocation; in short, all ports must enqueue in\n+order to reach the limit.\n+\n+If a port attempts to enqueue and has no credits available, the enqueue\n+operation will fail and the application must retry the enqueue. Credits are\n+replenished asynchronously by the DLB hardware.\n+\n+Software Credits\n+~~~~~~~~~~~~~~~~\n+\n+The DLB is a \"closed system\" event dev, and the DLB PMD layers a software\n+credit scheme on top of the hardware credit scheme in order to comply with\n+the per-port backpressure described in the eventdev API.\n+\n+The DLB's hardware scheme is local to a queue/pipeline stage: a port spends a\n+credit when it enqueues to a queue, and credits are later replenished after the\n+events are dequeued and released.\n+\n+In the software credit scheme, a credit is consumed when a new (.op =\n+RTE_EVENT_OP_NEW) event is injected into the system, and the credit is\n+replenished when the event is released from the system (either explicitly with\n+RTE_EVENT_OP_RELEASE or implicitly in dequeue_burst()).\n+\n+In this model, an event is \"in the system\" from its first enqueue into eventdev\n+until it is last dequeued. If the event goes through multiple event queues, it\n+is still considered \"in the system\" while a worker thread is processing it.\n+\n+A port will fail to enqueue if the number of events in the system exceeds its\n+``new_event_threshold`` (specified at port setup time). A port will also fail\n+to enqueue if it lacks enough hardware credits to enqueue; load-balanced\n+credits are used to enqueue to a load-balanced queue, and directed credits are\n+used to enqueue to a directed queue.\n+\n+The out-of-credit situations are typically transient, and an eventdev\n+application using the DLB ought to retry its enqueues if they fail.\n+If enqueue fails, DLB PMD sets rte_errno as follows:\n+\n+- -ENOSPC: Credit exhaustion (either hardware or software)\n+- -EINVAL: Invalid argument, such as port ID, queue ID, or sched_type.\n+\n+Depending on the pipeline the application has constructed, it's possible to\n+enter a credit deadlock scenario wherein the worker thread lacks the credit\n+to enqueue an event, and it must dequeue an event before it can recover the\n+credit. If the worker thread retries its enqueue indefinitely, it will not\n+make forward progress. Such deadlock is possible if the application has event\n+\"loops\", in which an event in dequeued from queue A and later enqueued back to\n+queue A.\n+\n+Due to this, workers should stop retrying after a time, release the events it\n+is attempting to enqueue, and dequeue more events. It is important that the\n+worker release the events and don't simply set them aside to retry the enqueue\n+again later, because the port has limited history list size (by default, twice\n+the port's dequeue_depth).\n+\n+Priority\n+~~~~~~~~\n+\n+The DLB supports event priority and per-port queue service priority, as\n+described in the eventdev header file. The DLB does not support 'global' event\n+queue priority established at queue creation time.\n+\n+DLB supports 8 event and queue service priority levels. For both priority\n+types, the PMD uses the upper three bits of the priority field to determine the\n+DLB priority, discarding the 5 least significant bits. The 5 least significant\n+event priority bits are not preserved when an event is enqueued.\n+\n+Load-Balanced Queues\n+~~~~~~~~~~~~~~~~~~~~\n+\n+A load-balanced queue can support atomic and ordered scheduling, or atomic and\n+unordered scheduling, but not atomic and unordered and ordered scheduling. A\n+queue's scheduling types are controlled by the event queue configuration.\n+\n+If the user sets the ``RTE_EVENT_QUEUE_CFG_ALL_TYPES`` flag, the\n+``nb_atomic_order_sequences`` determines the supported scheduling types.\n+With non-zero ``nb_atomic_order_sequences``, the queue is configured for atomic\n+and ordered scheduling. In this case, ``RTE_SCHED_TYPE_PARALLEL`` scheduling is\n+supported by scheduling those events as ordered events. Note that when the\n+event is dequeued, its sched_type will be ``RTE_SCHED_TYPE_ORDERED``. Else if\n+``nb_atomic_order_sequences`` is zero, the queue is configured for atomic and\n+unordered scheduling. In this case, ``RTE_SCHED_TYPE_ORDERED`` is unsupported.\n+\n+If the ``RTE_EVENT_QUEUE_CFG_ALL_TYPES`` flag is not set, schedule_type\n+dictates the queue's scheduling type.\n+\n+The ``nb_atomic_order_sequences`` queue configuration field sets the ordered\n+queue's reorder buffer size. DLB has 4 groups of ordered queues, where each\n+group is configured to contain either 1 queue with 1024 reorder entries, 2\n+queues with 512 reorder entries, and so on down to 32 queues with 32 entries.\n+\n+When a load-balanced queue is created, the PMD will configure a new sequence\n+number group on-demand if num_sequence_numbers does not match a pre-existing\n+group with available reorder buffer entries. If all sequence number groups are\n+in use, no new group will be created and queue configuration will fail. (Note\n+that when the PMD is used with a virtual DLB device, it cannot change the\n+sequence number configuration.)\n+\n+The queue's ``nb_atomic_flows`` parameter is ignored by the DLB PMD, because\n+the DLB does not limit the number of flows a queue can track. In the DLB, all\n+load-balanced queues can use the full 16-bit flow ID range.\n+\n+Reconfiguration\n+~~~~~~~~~~~~~~~\n+\n+The Eventdev API allows one to reconfigure a device, its ports, and its queues\n+by first stopping the device, calling the configuration function(s), then\n+restarting the device. The DLB does not support configuring an individual queue\n+or port without first reconfiguring the entire device, however, so there are\n+certain reconfiguration sequences that are valid in the eventdev API but not\n+supported by the PMD.\n+\n+Specifically, the PMD supports the following configuration sequence:\n+1. Configure and start the device\n+2. Stop the device\n+3. (Optional) Reconfigure the device\n+4. (Optional) If step 3 is run:\n+\n+ a. Setup queue(s). The reconfigured queue(s) lose their previous port links.\n+ b. The reconfigured port(s) lose their previous queue links.\n+\n+5. (Optional, only if steps 4a and 4b are run) Link port(s) to queue(s)\n+6. Restart the device. If the device is reconfigured in step 3 but one or more\n+ of its ports or queues are not, the PMD will apply their previous\n+ configuration (including port->queue links) at this time.\n+\n+The PMD does not support the following configuration sequences:\n+1. Configure and start the device\n+2. Stop the device\n+3. Setup queue or setup port\n+4. Start the device\n+\n+This sequence is not supported because the event device must be reconfigured\n+before its ports or queues can be.\n+\n+Deferred Scheduling\n+~~~~~~~~~~~~~~~~~~~\n+\n+The DLB PMD's default behavior for managing a CQ is to \"pop\" the CQ once per\n+dequeued event before returning from rte_event_dequeue_burst(). This frees the\n+corresponding entries in the CQ, which enables the DLB to schedule more events\n+to it.\n+\n+To support applications seeking finer-grained scheduling control -- for example\n+deferring scheduling to get the best possible priority scheduling and\n+load-balancing -- the PMD supports a deferred scheduling mode. In this mode,\n+the CQ entry is not popped until the *subsequent* rte_event_dequeue_burst()\n+call. This mode only applies to load-balanced event ports with dequeue depth of\n+1.\n+\n+To enable deferred scheduling, use the defer_sched vdev argument like so:\n+\n+ .. code-block:: console\n+\n+ --vdev=dlb1_event,defer_sched=on\n+\n+Atomic Inflights Allocation\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+In the last stage prior to scheduling an atomic event to a CQ, DLB holds the\n+inflight event in a temporary buffer that is divided among load-balanced\n+queues. If a queue's atomic buffer storage fills up, this can result in\n+head-of-line-blocking. For example:\n+- An LDB queue allocated N atomic buffer entries\n+- All N entries are filled with events from flow X, which is pinned to CQ 0.\n+\n+Until CQ 0 releases 1+ events, no other atomic flows for that LDB queue can be\n+scheduled. The likelihood of this case depends on the eventdev configuration,\n+traffic behavior, event processing latency, potential for a worker to be\n+interrupted or otherwise delayed, etc.\n+\n+By default, the PMD allocates 16 buffer entries for each load-balanced queue,\n+which provides an even division across all 128 queues but potentially wastes\n+buffer space (e.g. if not all queues are used, or aren't used for atomic\n+scheduling).\n+\n+The PMD provides a dev arg to override the default per-queue allocation. To\n+increase a vdev's per-queue atomic-inflight allocation to (for example) 64:\n+\n+ .. code-block:: console\n+\n+ --vdev=dlb1_event,atm_inflights=64\n+\ndiff --git a/drivers/event/dlb/meson.build b/drivers/event/dlb/meson.build\nnew file mode 100644\nindex 0000000..54ba2c8\n--- /dev/null\n+++ b/drivers/event/dlb/meson.build\n@@ -0,0 +1,7 @@\n+# SPDX-License-Identifier: BSD-3-Clause\n+# Copyright(c) 2019-2020 Intel Corporation\n+\n+sources = files(\n+)\n+\n+deps += ['mbuf', 'mempool', 'ring', 'pci', 'bus_pci']\ndiff --git a/drivers/event/dlb/rte_pmd_dlb_event_version.map b/drivers/event/dlb/rte_pmd_dlb_event_version.map\nnew file mode 100644\nindex 0000000..299ae63\n--- /dev/null\n+++ b/drivers/event/dlb/rte_pmd_dlb_event_version.map\n@@ -0,0 +1,3 @@\n+DPDK_21.0 {\n+\tlocal: *;\n+};\ndiff --git a/drivers/event/meson.build b/drivers/event/meson.build\nindex ebe76a7..35060c6 100644\n--- a/drivers/event/meson.build\n+++ b/drivers/event/meson.build\n@@ -10,6 +10,10 @@ if not (toolchain == 'gcc' and cc.version().version_compare('<4.8.6') and\n \tdpdk_conf.has('RTE_ARCH_ARM64'))\n \tdrivers += 'octeontx'\n endif\n+if ((dpdk_conf.has('RTE_ARCH_X86_64') or dpdk_conf.has('RTE_ARCH_X86')) and\n+\tis_linux)\n+\tdrivers += 'dlb'\n+endif\n std_deps = ['eventdev', 'kvargs']\n config_flag_fmt = 'RTE_LIBRTE_@0@_EVENTDEV_PMD'\n driver_name_fmt = 'rte_pmd_@0@_event'\n", "prefixes": [ "v4", "01/22" ] }