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 2ABE6A04F2; Fri, 6 Dec 2019 17:33:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7AEF11BF92; Fri, 6 Dec 2019 17:33:09 +0100 (CET) Received: from mx0b-00169c01.pphosted.com (mx0a-00169c01.pphosted.com [67.231.148.124]) by dpdk.org (Postfix) with ESMTP id F3E361BF90 for ; Fri, 6 Dec 2019 17:33:06 +0100 (CET) Received: from pps.filterd (m0045114.ppops.net [127.0.0.1]) by mx0a-00169c01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xB6GHaf2029402 for ; Fri, 6 Dec 2019 08:33:05 -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=GaFdnKQAxWxa1geoAGthx8DQt3L5XDLYVHlCxsQa7Ms=; b=ra6vlw9U8MA691MwaHJ4JaZMlC0bZ+iresg3+hiOat5Pqpp3Xoqmm06Vh+idySIRqR7A 89Fxx9hRz0gB1kH8B1OQGBPw9WCp4ocC8yAX23XOoQG7fGOGfLKXzBd8t5mOkUtPs7Os oRiECiSDq6O9wcKvaaZE3/T2eEjzS/59QXPdNHNN3S32E6DCG214uIZ4J1y2BKgqJcGZ yXkpTdqcElzauhN7c18s9+sivCVDgjRlE4Z+JHirl9QykBN/khgMtcqWhRgzQhtwVHJe 6oEkwFaJW1wrNKJEMXJOaeCxK/LSa04v3EHCp+u9u9OznSR08VHL6kk0qMyKicBruCXD Hw== Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0a-00169c01.pphosted.com with ESMTP id 2wqp4d8t00-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 06 Dec 2019 08:33:05 -0800 Received: by mail-qk1-f200.google.com with SMTP id o184so4768432qkf.14 for ; Fri, 06 Dec 2019 08:33:05 -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=GaFdnKQAxWxa1geoAGthx8DQt3L5XDLYVHlCxsQa7Ms=; b=FqRsU36OaxypjplFGb+j7roixKCC8nsHbx+9ra/OIx/6VJm1Gjf640ypejTsV3CE3R EB5+eObOvxF6V90NhuGyR8+AuMXa+EKXuyi9OoUE10PgHEHPa+gfvpTuNR6RU+8tpDhu TlW46HY/cVtd7DTWARrMHh/rgdZfoVFzRYWctXBzDwlYZDKmmgxhAB7eWVoLKhxSSAWU aq9Mj/0HlALNwMAYHIH3DeMfJPlWsf5Crbt1Hv1Ka4uqiH2cRPu76pSKAYkaAGf82VIK HALUBB8Pvu3SlA4HK4rNhxLJeEFNPsMnw2a33bpxng1zr/PcRghWEE00XIZJLgMiJRIr lV/w== 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=GaFdnKQAxWxa1geoAGthx8DQt3L5XDLYVHlCxsQa7Ms=; b=occ6Xgk39zuf+2Zyo0R2TASJ+NAsVKx2AxP/4xIEw9LoxTCNzScOvhewkVyVDEu94f /nuU9a1F9kTniNTF4UQcfouBBLFTyoDUzq2dMM8jb9SPtC3/awrES6BHQbpLIlOuusbu +c69yoLpGIKM9V+EPDi71OKooAsAyOIIEBO8Hzs5beoorn2vFyTKgCndHTJzPld80JdG IssPA7drHUNIPsSNeQOVL3FTAaFUMgRGsmDIBd6qsnzJr3hhMCRndviTOp8tysdaszRY 9u/qYEtR2rMtu//zIG/Y2IjWt3Rx9c8CxHegqrch5Ya5vzQBGguUtioYpK3ik3nbvdmW kMwA== X-Gm-Message-State: APjAAAURluxQeY3NWd+vFlRakbk93+2noXMG+ektTlnpzwG4e15EbDha RFzGFRTwwV9SDHw+/KqeTNHRQQcpZ8JQ1TRNF7Fq5e+T9Ddpd3WpxHM+oMA7xk5BAuszNG6+oj8 iDImkYy9A8wRSgy+Q2WQ= X-Received: by 2002:a05:620a:6ce:: with SMTP id 14mr14299289qky.417.1575649984519; Fri, 06 Dec 2019 08:33:04 -0800 (PST) X-Google-Smtp-Source: APXvYqymm8jkjEjn9MCGiyXTdtX6KD/lPCf0owqch1Kqkx+JOUPVTvmz10YfsXIN5x2ogaFTcw9tTkcsmZglM0Yejeg= X-Received: by 2002:a05:620a:6ce:: with SMTP id 14mr14299192qky.417.1575649983387; Fri, 06 Dec 2019 08:33:03 -0800 (PST) MIME-Version: 1.0 References: <9e58e2a0-0a6a-4dec-ffe7-e9ea7cf33099@ericsson.com> In-Reply-To: <9e58e2a0-0a6a-4dec-ffe7-e9ea7cf33099@ericsson.com> From: Venky Venkatesh Date: Fri, 6 Dec 2019 08:32:54 -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_05:2019-12-05,2019-12-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 priorityscore=1501 bulkscore=0 mlxscore=0 clxscore=1015 spamscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 suspectscore=8 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1912060136 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" 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. 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 . 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. 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. Thanks -Venky On Fri, Dec 6, 2019 at 12:34 AM Mattias R=C3=B6nnblom < mattias.ronnblom@ericsson.com> wrote: > On 2019-12-06 01:26, Venky Venkatesh wrote: > > I see that the provision in 18.11 eventdev DSW for maximum number of > queues > > is > > > > #define DSW_MAX_QUEUES (16) > > > > > > > > 1. If the number of queues needed is to be increased to 7 bits (i.e= . > > 128) is there any issue (correctness, scale, performance) other tha= n > > increased data structure size? > > No. > > > 2. I see that it is only used in the following structs: > > - struct dsw_evdev: struct dsw_queue queues[DSW_MAX_QUEUES]; > > sizeof(struct dsw_queue) ~ DSW_MAX_FLOWS. So the total increase > > contribution here is (128-16)*DSW_MAX_FLOWS from about 0.5MB to > 4MB > > - struct dsw_port: uint64_t queue_enqueued[DSW_MAX_QUEUES], > > queue_dequeued[DSW_MAX_QUEUES]; > > This increase is negligible (a few KB at most across all > dsw_ports) > > On x86_64, the size of the dsw_evdev-struct is increased by ~32 kB per > queue added. > > > 3. So is it enough if I changed the above define? (In other words I > hope > > there are no other hidden/implicit dependencies on the current valu= e > 16 > > elsewhere in the code). Also I suppose the only way is to directly > change > > this in the code, rite? > > > > Yes, and yes. > > The original reason for having that define was that I thought 16 queues > would be enough for anyone. As so many in the past that has utter such > statements, I might well have been wrong. > > /M >