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 CC709A04F3; Fri, 6 Dec 2019 23:22:44 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 071D628EE; Fri, 6 Dec 2019 23:22:44 +0100 (CET) Received: from mx0b-00169c01.pphosted.com (mx0b-00169c01.pphosted.com [67.231.156.123]) by dpdk.org (Postfix) with ESMTP id 8316823D for ; Fri, 6 Dec 2019 23:22:42 +0100 (CET) Received: from pps.filterd (m0048189.ppops.net [127.0.0.1]) by mx0b-00169c01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB6MJ4Ao009905 for ; Fri, 6 Dec 2019 14:22:40 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=PPS12012017; bh=oJPoWBM0Crk+jCBpBi0+J1XTD4tL6N6Dx+0+PEjqzcM=; b=B/P2se/Lj+B7WLEpPpyEa5FgMrzFVK4P78RdskQs1gEuoctKyAQ9VQgY+kMTegJqWGox 72rSIrfQUREIKvb3FQZy2mB7bXiovYUhZBKV2l2KdGjD5xdMyI/bLG2TYJQtD+yvQTHh iC5dJtFN8Lum45tNaHJ41G/HrNmGAfm5ffijif+H0zbVjfddXF7p7ozx2WIOS7enGbEZ dVzAkhF9Mg2A7nlB3TsuhpjBhsE8NL3Ouw6Z0FoCNn30Rnr4JeryIY4YNC+a/JJ5NuI5 icUnIfCq32PFirrzU2RHgxPQFbedwrtUogE9YHxJhyaoxgzrpmOx8/ZhJECsKhgmxXPv AQ== Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by mx0b-00169c01.pphosted.com with ESMTP id 2wqmtjj7pc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 06 Dec 2019 14:22:40 -0800 Received: by mail-qv1-f70.google.com with SMTP id z9so759076qvo.10 for ; Fri, 06 Dec 2019 14:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paloaltonetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oJPoWBM0Crk+jCBpBi0+J1XTD4tL6N6Dx+0+PEjqzcM=; b=0D31Vv0oZ3GFuc61tZfVH5eo8/7k34BiGloIK7PivaXfZ3vIoPIaB2dshZ8Cl+rhSM ZnlfGSpZ4yhXwwp1oqkJqz0+XhowBrVAnama383fTGrxkQC+3P2XZeNvN9dpKIFk2bek 9HQ0C+qYCRH+b5K+UpMvD3QSOZlC6YHeY22pUEL8tH+setIto/ppsUJy/Je0xkiQ1grZ yEiaSw+14hUZ0c3lLY4Deikqlq2Rv76MdYKu9b0RYXnBaXegLcmnAsuR1bay4VCQIux/ IsDPZwSAhfVMadW+uPmP956iMiPqHkFCNA2Y00dEZMeb8/N1EnJ3bA1s9q57oyvVptJQ CCbQ== 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; bh=oJPoWBM0Crk+jCBpBi0+J1XTD4tL6N6Dx+0+PEjqzcM=; b=pMTz37CJDsrk1RyjRxm2L7hVdM+DZW566PdTsQ+QTB0WiSdpbJ5j8/9fR/3xjWmDEd QuCM7dyKR7//8cTHl241iDDz5Kd4XLNNLBAlvfn0AowTyTMIx7ePV+RPPSLHGMOhYCED d+j3k1K8StxOL2DXuRXHE1lr+rfCgmeGkImLu9tA/HAUKxLatmq9r6Ocn7WlUavv2pHv WpCyUrXDcdE3SqRsDny7PxOBtSUpFJWQPL7F8NFXtLEIvmpkM8fQIJKj1wTBpHqA0x57 RaNBVBoak4ig+IfJbWAZB65lFKkQ1vTjZQuYKXq0YWyRHIm60YenEBtNBNa+6rdABPy1 5K7Q== X-Gm-Message-State: APjAAAV4+3NNb1aF4HpO2MHNxeR10k4Mfv5pJL3ZwNB+0KhYBSXLeev+ Ug30qOCfTRvfdW9AVIJylgWdeZEN/S9hF44W6CaR47vn4qRuNpC+qmbqN7aHDEHn/6ljaZr0laj 4VnrlINmlIKLC+yYGG7I= X-Received: by 2002:ac8:e4a:: with SMTP id j10mr15843442qti.340.1575670959138; Fri, 06 Dec 2019 14:22:39 -0800 (PST) X-Google-Smtp-Source: APXvYqyXzJMfjYNIE3rlzxwV+JfgP46UscaPn/wHM7rMMIhFAlg/cK+A496rrAwyQ1koo59yl77yKbbZ+N+0TUKMZT4= X-Received: by 2002:ac8:e4a:: with SMTP id j10mr15843421qti.340.1575670958876; Fri, 06 Dec 2019 14:22:38 -0800 (PST) MIME-Version: 1.0 References: <9e58e2a0-0a6a-4dec-ffe7-e9ea7cf33099@ericsson.com> In-Reply-To: From: Venky Venkatesh Date: Fri, 6 Dec 2019 14:22:28 -0800 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: dev@dpdk.org X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-06_07:2019-12-05,2019-12-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 clxscore=1015 adultscore=0 suspectscore=1 phishscore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912060176 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" To my understanding, per eventdev API, events are considered in flight between NEW to RELEASE (implicit/explicit). 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 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. 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=C3=B6nnblom < 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 FORWARD= s > > should not fail -- which can happen with the current design as some NEW= s > > 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. >