From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 95CA3A059F; Fri, 10 Apr 2020 15:00:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C54881BF57; Fri, 10 Apr 2020 15:00:41 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 29FFD1BE9C for ; Fri, 10 Apr 2020 15:00:40 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id z12so1717381ilb.10 for ; Fri, 10 Apr 2020 06:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WSbFSbN/VJfe7BsbuHF4IkeHmEBSlUSgNsw+59xLEv4=; b=cYbzSchw2OiC3yzi5/4JL3M6P/Udr43Gqji1bax8WEwyH+k+hRSyJoeCaJFspFw9h+ HpT+YhJn57FKD1Epqob2n8leu9f07WBM2NotfDyd3E4leJNTWekLs1640Hx6vKvInqIg uD/W7NL67Fh2WAkFKcixnV/oha9dD0T3uXccGDCAbfFiHHl7S3RmdRz1Rczj1OI6IKOX vaL/W/0u80bXf0iygM77Lw1zKOZHArjYN0OWvnmEayD2QVEgdtaiIL3G6hmkppq2t6jL rPqR5YnQCe9EEzLr45DLJ5EQUMenhKvd32PNC+u3ftdymesa8LN5f3KmaFm6FqQPnnLc 16Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WSbFSbN/VJfe7BsbuHF4IkeHmEBSlUSgNsw+59xLEv4=; b=MoGSGIatShcYmUOSRaVu4bXkjYXCttqP3S0N2qgwl8rwKWBoJ79qu0Bs4vbIKrvrSs H72RvI7UM3NFVUBI06OJiA+9MEs3fnZVKNkRQT4Ca2QspFD19N1Z1B/3i5kSNUJrHo0n jMxkCJ+bLEvFS+/mjpN5/Lc/Q4PzXP4Ld7Sil3V8Wxb1Ni77lSvXIN5i3hvZ1GPY7qCA qNjHeVw3ubJVjr3ugP/QTvyNYwPCjHASUrfRf3dU1QRTzHs9zUnRIne0z54z3SnNL8PK 4HP5z31Y+g+/BbeNH54y2ckCuwD63azoZfrqHuEP2dkVEP+yG3wWvevAXnjRlJ3jl2wC K27A== X-Gm-Message-State: AGi0PubtowLHhGy2TBfspjPQMJO2MANRuZzKMSW2XFNJ2dRKo/Yhz1SL Rk9FC0KPylI8ug61005CkYt8Prb3m05pS7q7MFM= X-Google-Smtp-Source: APiQypI8FFPE89wtWVfHZ1bd35NWJplkALrs5hSpGsrwp9gwz7Jzeq9qF6bD4luYB7hfgHezRkFzHRvxFZMR+Setl88= X-Received: by 2002:a92:9edb:: with SMTP id s88mr5246853ilk.294.1586523639266; Fri, 10 Apr 2020 06:00:39 -0700 (PDT) MIME-Version: 1.0 References: <20200408175655.18879-1-mattias.ronnblom@ericsson.com> <86ff8b8f-7865-7fe2-f853-e88d2a64347d@ericsson.com> <2d7196e0-9edf-5753-f834-0e231eb3de43@ericsson.com> In-Reply-To: <2d7196e0-9edf-5753-f834-0e231eb3de43@ericsson.com> From: Jerin Jacob Date: Fri, 10 Apr 2020 18:30:23 +0530 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: dpdk-dev , Jerin Jacob , Gage Eads , Bruce Richardson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC 1/3] eventdev: allow for event devices requiring maintenance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Apr 9, 2020 at 7:32 PM Mattias R=C3=B6nnblom wrote: > > On 2020-04-09 15:32, Jerin Jacob wrote: > > On Thu, Apr 9, 2020 at 5:51 PM Mattias R=C3=B6nnblom > > wrote: > >> On 2020-04-08 21:36, Jerin Jacob wrote: > >>> On Wed, Apr 8, 2020 at 11:27 PM Mattias R=C3=B6nnblom > >>> wrote: > >>>> Extend Eventdev API to allow for event devices which require various > >>>> forms of internal processing to happen, even when events are not > >>>> enqueued to or dequeued from a port. > >>>> > >>>> Signed-off-by: Mattias R=C3=B6nnblom > >>>> --- > >>>> lib/librte_eventdev/rte_eventdev.h | 65 +++++++++++++++++++++= +++++ > >>>> lib/librte_eventdev/rte_eventdev_pmd.h | 14 ++++++ > >>>> 2 files changed, 79 insertions(+) > >>>> > >>>> diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventde= v/rte_eventdev.h > >>>> index 226f352ad..d69150792 100644 > >>>> --- a/lib/librte_eventdev/rte_eventdev.h > >>>> +++ b/lib/librte_eventdev/rte_eventdev.h > >>>> @@ -289,6 +289,15 @@ struct rte_event; > >>>> * single queue to each port or map a single queue to many port. > >>>> */ > >>>> > >>>> +#define RTE_EVENT_DEV_CAP_REQUIRES_MAINT (1ULL << 9) > >>>> +/**< Event device requires calls to rte_event_maintain() during > >>> This scheme would call for DSW specific API handling in fastpath. > >> > >> Initially this would be so, but buffering events might yield performan= ce > >> benefits for more event devices than DSW. > >> > >> > >> In an application, it's often convenient, but sub-optimal from a > >> performance point of view, to do single-event enqueue operations. The > >> alternative is to use an application-level buffer, and the flush this > >> buffer with rte_event_enqueue_burst(). If you allow the event device t= o > >> buffer, you get the simplicity of single-event enqueue operations, but > >> without taking any noticeable performance hit. > > IMO, It is better to aggregate the burst by the application, as sendin= g > > event by event to the driver to aggregate has performance due to cost > > function pointer overhead. > > > That's a very slight overhead - but for optimal performance, sure. It'll > come at a cost in terms of code complexity. Just look at the adapters. > They do this already. I think some applications are ready to take the > extra 5-10 clock cycles or so it'll cost them to do the function call > (provided the event device had buffering support). So Is there any advantage of moving aggregation logic to PMD? it is costly. > > > > Another concern is the frequency of calling rte_event_maintain() functi= on by > > the application, as the timing requirements will vary differently by > > the driver to driver and application to application. > > IMO, It is not portable and I believe the application should not be > > aware of those details. If the driver needs specific maintenance > > function for any other reason then better to use DPDK SERVICE core infr= a. > > > The only thing the application needs to be aware of, is that it needs to > call rte_event_maintain() as often as it would have called dequeue() in > your "typical worker" example. To make sure this call is cheap-enough is > up to the driver, and this needs to hold true for all event devices that > needs maintenance. Why not rte_event_maintain() can't do either in dequeue() or enqueue() in the driver context? Either one of them has to be called periodically by application in any case? > > > If you plan to use a non-buffering hardware device driver or a soft, > centralized scheduler that doesn't need this, it will also not set the > flag, and thus the application needs not care about the > rte_event_maintain() function. DPDK code such as the eventdev adapters > do need to care, but the increase in complexity is slight, and the cost > of calling rte_maintain_event() on a maintenance-free devices is very > low (since the then-NULL function pointer is in the eventdev struct, > likely on a cache-line already dragged in). > > > Unfortunately, DPDK doesn't have a per-core delayed-work mechanism. > Flushing event buffers (and other DSW "background work") can't be done > on a service core, since they would work on non-MT-safe data structures > on the worker thread's event ports. Yes. Otherwise, DSW needs to update to support MT safe. > > > >> > >>>> + * periods when neither rte_event_dequeue_burst() nor > >>> The typical worker thread will be > >>> while (1) { > >>> rte_event_dequeue_burst(); > >>> ..proess.. > >>> rte_event_enqueue_burst(); > >>> } > >>> If so, Why DSW driver can't do the maintenance in driver context in > >>> dequeue() call. > >>> > >> DSW already does maintenance on dequeue, and works well in the above > >> scenario. The typical worker does not need to care about the > >> rte_event_maintain() functions, since it dequeues events on a regular = basis. > >> > >> > >> What this RFC addresses is the more atypical (but still fairly common) > >> case of a port being neither dequeued to or enqueued from on a regular > >> basis. The timer and ethernet rx adapters are examples of such. > > If it is an Adapter specific use case problem then maybe, we have > > an option to fix the problem in adapter specific API usage or in that a= rea. > > > > It's not adapter specific, I think. There might be producer-only ports, > for example, which doesn't provide a constant stream of events, but > rather intermittent bursts. A traffic generator is one example of such > an application, and there might be other, less synthetic ones as well. In that case, the application knows the purpose of the eventdev port. Is changing eventdev spec to configure "port" or "queue" for that use case help? Meaning, DSW or Any driver can get the hint and change the function pointers accordingly for fastpath. For instance, do maintenance on enqueue() for such ports or so. > > > >> > >>>> + * rte_event_enqueue_burst() are called on a port. This will allow = the > >>>> + * event device to perform internal processing, such as flushing > >>>> + * buffered events, return credits to a global pool, or process > >>>> + * signaling related to load balancing. > >>>> + */ > >> >