From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 46C3243AE5; Sat, 10 Feb 2024 08:24:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CC698402DA; Sat, 10 Feb 2024 08:24:35 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id A12C140150 for ; Sat, 10 Feb 2024 08:24:33 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id C6CF143CB for ; Sat, 10 Feb 2024 08:24:32 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id BA618436F; Sat, 10 Feb 2024 08:24:32 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.4 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 98D7C42F1; Sat, 10 Feb 2024 08:24:30 +0100 (CET) Message-ID: <381c64e4-4d45-44ee-8fa5-433c44b38fc0@lysator.liu.se> Date: Sat, 10 Feb 2024 08:24:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 01/11] eventdev: improve doxygen introduction text To: Jerin Jacob Cc: Bruce Richardson , dev@dpdk.org, jerinj@marvell.com, mattias.ronnblom@ericsson.com, abdullah.sevincer@intel.com, sachin.saxena@oss.nxp.com, hemant.agrawal@nxp.com, pbhagavatula@marvell.com, pravin.pathak@intel.com References: <20240119174346.108905-1-bruce.richardson@intel.com> <20240202123953.77166-1-bruce.richardson@intel.com> <20240202123953.77166-2-bruce.richardson@intel.com> <7177dc02-8e31-47cd-baf2-41cb3eee6fe4@lysator.liu.se> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2024-02-09 09:43, Jerin Jacob wrote: > On Thu, Feb 8, 2024 at 3:20 PM Mattias Rönnblom wrote: >> >> On 2024-02-07 11:14, Jerin Jacob wrote: >>> On Fri, Feb 2, 2024 at 7:29 PM Bruce Richardson >>> wrote: >>>> >>>> Make some textual improvements to the introduction to eventdev and event >>>> devices in the eventdev header file. This text appears in the doxygen >>>> output for the header file, and introduces the key concepts, for >>>> example: events, event devices, queues, ports and scheduling. >>>> >>>> This patch makes the following improvements: >>>> * small textual fixups, e.g. correcting use of singular/plural >>>> * rewrites of some sentences to improve clarity >>>> * using doxygen markdown to split the whole large block up into >>>> sections, thereby making it easier to read. >>>> >>>> No large-scale changes are made, and blocks are not reordered >>>> >>>> Signed-off-by: Bruce Richardson >>> >>> Thanks Bruce, While you are cleaning up, Please add following or >>> similar change to fix for not properly >>> parsing the struct rte_event_vector. i.e it is coming as global >>> variables in html files. >>> >>> l[dpdk.org] $ git diff >>> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h >>> index e31c927905..ce4a195a8f 100644 >>> --- a/lib/eventdev/rte_eventdev.h >>> +++ b/lib/eventdev/rte_eventdev.h >>> @@ -1309,9 +1309,9 @@ struct rte_event_vector { >>> */ >>> struct { >>> uint16_t port; >>> - /* Ethernet device port id. */ >>> + /**< Ethernet device port id. */ >>> uint16_t queue; >>> - /* Ethernet device queue id. */ >>> + /**< Ethernet device queue id. */ >>> }; >>> }; >>> /**< Union to hold common attributes of the vector array. */ >>> @@ -1340,7 +1340,11 @@ struct rte_event_vector { >>> * vector array can be an array of mbufs or pointers or opaque u64 >>> * values. >>> */ >>> +#ifndef __DOXYGEN__ >>> } __rte_aligned(16); >>> +#else >>> +}; >>> +#endif >>> >>> /* Scheduler type definitions */ >>> #define RTE_SCHED_TYPE_ORDERED 0 >>> >>>> >>>> --- >>>> V3: reworked following feedback from Mattias >>>> --- >>>> lib/eventdev/rte_eventdev.h | 132 ++++++++++++++++++++++-------------- >>>> 1 file changed, 81 insertions(+), 51 deletions(-) >>>> >>>> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h >>>> index ec9b02455d..a741832e8e 100644 >>>> --- a/lib/eventdev/rte_eventdev.h >>>> +++ b/lib/eventdev/rte_eventdev.h >>>> @@ -12,25 +12,33 @@ >>>> * @file >>>> * >>>> * RTE Event Device API >>>> + * ==================== >>>> * >>>> - * In a polling model, lcores poll ethdev ports and associated rx queues >>>> - * directly to look for packet. In an event driven model, by contrast, lcores >>>> - * call the scheduler that selects packets for them based on programmer >>>> - * specified criteria. Eventdev library adds support for event driven >>>> - * programming model, which offer applications automatic multicore scaling, >>>> - * dynamic load balancing, pipelining, packet ingress order maintenance and >>>> - * synchronization services to simplify application packet processing. >>>> + * In a traditional run-to-completion application model, lcores pick up packets >>> >>> Can we keep it is as poll mode instead of run-to-completion as event mode also >>> supports run to completion by having dequuee() and then Tx. >>> >> >> A "traditional" DPDK app is both polling and run-to-completion. You >> could always add "polling" somewhere, but "run-to-completion" in that >> context serves a purpose, imo. > > Yeah. Some event devices can actually sleep to save power if packet is > not present(using WFE in arm64 world). > Sure, and I believe you can do that with certain Ethdevs as well. Also, you can also use interrupts. So polling/energy-efficient polling (wfe/umwait)/interrupts aren't really a differentiator between Eventdev and "raw" Ethdev. > I think, We can be more specific then, like > > In a traditional run-to-completion application model where packet are > dequeued from NIC RX queues, ....... > "In a traditional DPDK application model, the application polls Ethdev port RX queues to look for work, and processing is done in a run-to-completion manner, after which the packets are transmitted on a Ethdev TX queue. Load is distributed by statically assigning ports and queues to lcores, and NIC receive-side scaling (RSS, or similar) is employed to distribute network flows (and thus work) on the same port across multiple RX queues." I don̈́'t know if that's too much. > >> >> A single-stage eventdev-based pipeline will also process packets in a >> run-to-completion fashion. In such a scenario, the difference between >> eventdev and the "tradition" lies in the (ingress-only) load balancing >> mechanism used (which the below note on the "traditional" use of RSS >> indicates).