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 DA78AA04F3; Sat, 7 Dec 2019 20:35:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 886341DBC; Sat, 7 Dec 2019 20:35:19 +0100 (CET) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 76E7023D for ; Sat, 7 Dec 2019 20:35:18 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id DDF0F40008 for ; Sat, 7 Dec 2019 20:35:17 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id C772140007; Sat, 7 Dec 2019 20:35:17 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.2 X-Spam-Score: -0.2 Received: from [192.168.1.59] (host-95-205-107-14.mobileonline.telia.com [95.205.107.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id E0A8F40002; Sat, 7 Dec 2019 20:35:16 +0100 (CET) To: Venky Venkatesh Cc: dev@dpdk.org References: <9e58e2a0-0a6a-4dec-ffe7-e9ea7cf33099@ericsson.com> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: Date: Sat, 7 Dec 2019 20:35:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] eventdev DSW question 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 2019-12-06 23:22, Venky Venkatesh wrote: > To my understanding, per eventdev API, events are considered in flight > between NEW to RELEASE (implicit/explicit). DSW considers events to be in flight between time of enqueue (on the source port), to the time of release (on the destination port). This is regardless if they are FORWARD or NEW-type events. The SW event device only counts NEW events toward the max number of in-flights events limitation. It will however release the atomic context and return the credits at step 4 below. Since there's no centralized point which can backpressure FORWARD events (which I think is how SW avoids being overwhelmed by FORWARDed events), DSW needs to ensure that the max_num_events is never exceeded. > Now consider an event (event-1) going thru the following stages: > > 1. NEW from core-3 > 2. dequeued by core-1 > 3. FORWARD > 4. core-1 does a next dequeue The event is RELEASEd already at this point. > 5. dequeued by core-2 > 6. RELEASE by core-2/implicit release on next dequeue by core-2 > > The way I understand DSW implementation this event would use credit at step > 1 AND step 3 while releasing in step2 -- right now credit usage is for > non_release (i.e NEW and FORWARD). So if between step-2 and step-3 another > core puts in a NEW of event-2 that could utilize all the credits of the > system and could thus fail step-3 of event-1. The NEW events producer ports' new_event_threshold should be significantly lower than the maximum numbers of in-flight events, and thus leave credits for FORWARDed events. > This to my knowledge is not conformant with eventdev. One way to address > this is to track the credits for that which are currently in core and not > make those credits available to NEW but only for FORWARDs ... there are > more details of course. > > Hope this explains > Thanks > -Venky > > > > On Fri, Dec 6, 2019 at 12:37 PM Mattias Rönnblom < > mattias.ronnblom@ericsson.com> wrote: > >> On 2019-12-06 17:32, Venky Venkatesh wrote: >>> Thanks Mattias for the clarifications. >>> >>> 1 more question: This time it is about the inflight accounting for DSW. >>> Here is my understanding: it seems to consider only the events which >>> are *inside >>> the scheduler* as in flight. >> >> Yes, like all event devices, I believe. >> >>> I am trying to distinguish it from those which >>> have been currently given to cores by the scheduler. The latter are not >>> considered in flight since we dsw_port_return_credits as soon as >>> dsw_event_dequeue_burst. >> >> A new dequeue means an implicit release of all unreleased events >> dequeued in the previous call. It's standard Eventdev semantics. >> >>> So if these events which are in core currently do >>> a FORWARD, there is a chance that those can fail. Ideally those FORWARDs >>> should not fail -- which can happen with the current design as some NEWs >>> can hog those credits freed up by the ones which have been dequeued by >>> cores. >> >> What you do to avoid this situation is set the new_event_threshold >> low-enough, so NEW events don't block FORWARDed ones. >> >>> Is this design of DSW intentional or an omission? If it is an >>> omission I can work on a possible fix and run it by you. >>> >> >> This is not really a DSW design, but rather how Eventdev works. >>