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 0DF03A0C41; Wed, 17 Nov 2021 11:53:21 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 878504068C; Wed, 17 Nov 2021 11:53:20 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 82F3540040 for ; Wed, 17 Nov 2021 11:53:18 +0100 (CET) X-IronPort-AV: E=McAfee;i="6200,9189,10170"; a="297345264" X-IronPort-AV: E=Sophos;i="5.87,241,1631602800"; d="scan'208";a="297345264" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Nov 2021 02:53:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,241,1631602800"; d="scan'208";a="536241691" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by orsmga001.jf.intel.com with ESMTP; 17 Nov 2021 02:53:17 -0800 Received: from orsmsx606.amr.corp.intel.com (10.22.229.19) by ORSMSX605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 17 Nov 2021 02:53:16 -0800 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx606.amr.corp.intel.com (10.22.229.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Wed, 17 Nov 2021 02:53:16 -0800 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.169) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Wed, 17 Nov 2021 02:53:16 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h/BDjIRG0iIAAFCYxHAC6WjD6Pp0UN1ByP4QYVRyV1DjN7M9eiAIyzaF5BWyzwBzsOqJ3ECQKc9bFzUO4MLWPH4JQR2RrRpylqoFMvQ2ChGP6c/Z7k0nk4/k93i13CT0xhkcH8RfpaO+bq/hANXkB2JM9a7W/L5ZJMBZGZfD2dENt2VYLohyprNC2jZdlFQLokms2YJ3cqI72UkGP34HVzEKr/tkpRLPegO8up0fw06SF3HKX0NxNIK7TALUoM25lhHEg1So0KhG9udffbQnHsSli1ZfktvuJ+EQPId7Xg4rhK5Qk29GnqouWFEOoUewYhuGzhTww6hBBp+vGTjfQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zy8rOR8nMqSQCryOBDqEjUZA10Tw4jIA8eSLFUiEZzE=; b=CQQPz3b8L9hA2e+S7FyOS4jkTfeGXXJ6Bds/Dc8DCeS+Qj4jpfyXpK+HmWa88CZWhdkQrsG2XWHqDbdwwUnZ/7xHdQPB5sJtRZ+eMHRRR4ICoUfSJyTQctW+V7WTvdrYtExS8VPAmgMPDleXPJq3QiWD3INUBEvP/zRypZvCEn4V3XwsFzwqfBNfues33wVPRTxkTfVkBzcaSUJ6/1A8eExQCrYvfT6QyO6rNjhTW6KXMITX9c+G6GrpK3mBw8/6t9NVj1nyz1edlnEBV8Y3VdmZp5whIEOuxZS0hEgkNUMJOG2yVW4bgWBJM6UcBul7vzUoSKHUYhxPamenQm+DzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zy8rOR8nMqSQCryOBDqEjUZA10Tw4jIA8eSLFUiEZzE=; b=XETHWvhYq31mxqVuKHvGOLp6O45uXWy+ZWVkRP+qFUP4wlo00bBLcKk7DwiDK8A+cNfJJvxWVerBWR11n3kTuVpGYt783NmF6S7zE1zagz7VN5TQRog3pUnzXc6YPgdDBeQcGyn0jTiU9kTz+5gL4dEIYrXqlAN/T4b+LAkHXZo= Received: from DM8PR11MB5670.namprd11.prod.outlook.com (2603:10b6:8:37::12) by DM8PR11MB5637.namprd11.prod.outlook.com (2603:10b6:8:33::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.19; Wed, 17 Nov 2021 10:53:14 +0000 Received: from DM8PR11MB5670.namprd11.prod.outlook.com ([fe80::c0f1:1135:ceb5:ac10]) by DM8PR11MB5670.namprd11.prod.outlook.com ([fe80::c0f1:1135:ceb5:ac10%9]) with mapi id 15.20.4669.016; Wed, 17 Nov 2021 10:53:14 +0000 From: "Dumitrescu, Cristian" To: Thomas Monjalon , "Singh, Jasvinder" , "Ananyev, Konstantin" CC: "dev@dpdk.org" Subject: RE: [dpdk-dev] [PATCH v2 2/2] qos: rearrange enqueue procedure Thread-Topic: [dpdk-dev] [PATCH v2 2/2] qos: rearrange enqueue procedure Thread-Index: AQHX256NAWpGwcG4RUO6+XwaUHYf/qwHizHQ Date: Wed, 17 Nov 2021 10:53:14 +0000 Message-ID: References: <20210316170723.22036-1-konstantin.ananyev@intel.com> <3756923.HVIXXKutY6@thomas> In-Reply-To: <3756923.HVIXXKutY6@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.6.200.16 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2aaa79a6-5d5f-475e-8913-08d9a9b87498 x-ms-traffictypediagnostic: DM8PR11MB5637: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: snCfFYRXcPJGTWJKnuho7A51lPO+GAlgKHsyxWVbn1RfUNDxxfAEl3r5OmD1F9x8mwnUgCxS8hB0VGXh6LwbI24l//nrlEejzGPWI+d/VZ8GpCM6JeYGHNYT5fX3Dh94luSMiAEJVTqM+jxiu3O7ZHhhh/civvjPuYFFy5B9eIVeL8mXqJVW2s1t6UbjQVb0fw5DpZnvXacQqmmN7ePTAvv74IzCYoxM8d8cUwxlZlb+eC0gsR0xk4u85toCCLgjBWSisT5IQvx2nSaz5sdgdeBbitjhO+JqdThY2cYQWKBfsiTemStfdli8wuXFBIEAE0gQMu4wVbYCsyBy5OMElHC/ZraI+hm95Od48kNfr9bW3eg8mDSpM7LWBUyCTbrMaQWkgOFRkEqVznnbzgZ7SmyXY+uhJ3vsOZWL4neALXE1rpLblbden3Q2sPIsgTzs6Ob1PbaSvt1xzNfr54C8yLJD4bwv+mXfHmQ/Fzc+M0GG+PiiwbMGp1J3L1e5IE7mTZyw/87/CVOQ5EZN1RSHgHBfrnmqmRWHqphtRwRrT9LErTdAYIBGdi3afWyKVyDWRJxaL6h4RKxJVYU8UPzor/uZi4wGycI8zIi5Fhr7jB7Epl40l8AIplVOpJPfYC5ilRizxRlXUgRULfacYR8NeUV3tWd7dNUSNoQ7XrJZ+HcxIk1o/S4TH8Les/7x9Ku+Wg8KngycFwzBmpXk+Di0Ug== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR11MB5670.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(7696005)(53546011)(6506007)(186003)(38100700002)(4326008)(55016002)(9686003)(71200400001)(2906002)(76116006)(110136005)(52536014)(316002)(8936002)(508600001)(38070700005)(6636002)(86362001)(5660300002)(122000001)(26005)(82960400001)(83380400001)(66476007)(8676002)(66556008)(64756008)(66446008)(33656002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?q6lRX5StarVe3v2h354xXaxM593I1FvURZPGqH6eH61OTDo0p9YJYUwTrH9D?= =?us-ascii?Q?kXPm9xJXh4k4rvkddgNFaWGEmd0yIRdlG3kkoGoU5iPNE8+ImPtdfe517XvF?= =?us-ascii?Q?IJgxa4fQv6o8Wt1+6BA1cYNydcaX/CLVO4m0E3gfomnImfnefqE1BNTZJkse?= =?us-ascii?Q?03lfT0s/UghMPIB1+8XqqCiGR9oSrAaHPUtOBWXz6/1ktjHSq4k7icKT6EuU?= =?us-ascii?Q?hRRYCK3ptV3Cnbbwzfv7/XPuQAW3KzMd99/wM8J2o2Wr/xvqga+dZF15Q6FH?= =?us-ascii?Q?lBZUXReolp3r1JnLLnJ7W6np45UzFDyCqIO2jqteFy3UMu26IeQSjL5vSj56?= =?us-ascii?Q?uoLVlfWcYErL5mT70ldLweI9sdh4dclT0msDTK8cSzCutIjhJFfPtUqOfWg9?= =?us-ascii?Q?eqec0F5oa+/NPj5EErjSBLlL6Da3c0DNkws5/fg2GJKj/RtxUN5O/0US+SE2?= =?us-ascii?Q?U8mjvQUnyoXAV6LJEX6guN69ndZOTHkSaL+bIPIc6c3RTH34EgpOA1zJeT4j?= =?us-ascii?Q?++mgYjEAnDgF2YpcQOGFr12EcGc7J9FvmMWqjHSrWOo8wlEFXcUTc1b/GO7h?= =?us-ascii?Q?23aI6iVAluaoXQJ+P+eSTnKvUq57+b+RvbkAMyT5jRrCs5hbjdUxGGbPRO9p?= =?us-ascii?Q?y0/IAA0B0SCQ+GbsWcDkx2nNe5j2DSEDosybodpylhDyKz+KrP7yt69Y+DnP?= =?us-ascii?Q?jpqyEj13k/cl4TiIO459GVY0bWas26NwgJ/Bfn20TYo8HeJb/hQHkga8n1mP?= =?us-ascii?Q?kohcEcHgV1+GcUdn9GB2kTcWQzHWDDp0+Zdze39pBhnAgKp5yS5+M54xptoi?= =?us-ascii?Q?T+GT8tvhrxe64QvGDfwdvrhfGVSdz8G1p4nuM369+XpvkyKGc1Rbi+b0XQn6?= =?us-ascii?Q?g40TzVzI5c8hihaLyKZUcJehHMRMrtB+moFRG7P4RWHWaSTxQwCZ0wLAT3od?= =?us-ascii?Q?bu67Nmcy4BcVkvsDNbWz8vhtmROi+UQt51dY4AZCxdBuK+MFk7NGvjzoc54M?= =?us-ascii?Q?QaFZEMp9sKqXNBO2TkemcDiRiKcWshpB1qz/LAP5Idj0At4puYy1dpzgcYWt?= =?us-ascii?Q?Hkr9l9rLEKwkxPmmJKRdxlPQHB7DvasiEcrJjx4UUjE8NGkbEG6yLBkK+LO/?= =?us-ascii?Q?MmRLf9d3LkQF5Mw3/NVj4BgaK1NQ/R91TMqTPdsygxQu+uzKG8YG0391f88y?= =?us-ascii?Q?53bIgNdTwe8omIKU6D3Fv+opTpsajoljaWFX1an3dsA1MujVNgasKKTz9VAc?= =?us-ascii?Q?CE5TNbLREvkqMMTT7Fr0XibDVUW6cPNktpo5NSHKU+5pMM6jzlXm+E1Y+zSc?= =?us-ascii?Q?K65sExDgCgFQPbIsdayG2rrVZ/xrth7dMKw9ReksstSoRfWlZ8bXoR6FaEKL?= =?us-ascii?Q?SnKUy9hvs5mszDyA0Ci8xdCxnyKdu8MPrRCy8B+jRd/vxV3HRcGVy9uQzHck?= =?us-ascii?Q?LdSID0O1/pDNdi77zyDuhEZy4+iUyEZ+UGBh8P/terXm/WkwL5+VXM3LTtT5?= =?us-ascii?Q?oc6PJ/iZWVODTi5JLg1Fs6ZiwSd6vmV05o9GXmNJRECbxgn1jzd+VeTNKNvt?= =?us-ascii?Q?5XBHSBTns+tGVZQ8bm8fyHbmzpxPREJ0uSwxOLoqKarqUzE4VqoXpBZ96HRO?= =?us-ascii?Q?xVs1NgxVGYR/neD9wPHmxidhaJVTh5A6n8u3i3y0X86LQvyEAaXpcfAr4hJK?= =?us-ascii?Q?F+SLqw=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR11MB5670.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2aaa79a6-5d5f-475e-8913-08d9a9b87498 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2021 10:53:14.4139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HYtOQ2sDfbV9MRBY1+V44yXLZBC3v8pRRXF7yiIB7xV546Db8W8HZFYR5hOFKFva6gu6XKi+Eoqtb68rRNbWWGo9tN9Cw73RqhDJc+aWadg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR11MB5637 X-OriginatorOrg: intel.com 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 > -----Original Message----- > From: Thomas Monjalon > Sent: Wednesday, November 17, 2021 10:33 AM > To: Dumitrescu, Cristian ; Singh, Jasvinde= r > ; Ananyev, Konstantin > > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 2/2] qos: rearrange enqueue procedure >=20 > Hi all, > What is the conclusion for this patch and the number 1/2? >=20 > 04/04/2021 01:53, Ananyev, Konstantin: > > > > Hi guys, > > > > > > > In many usage scenarios input mbufs for rte_sched_port_enqueue() > are > > > > not > > > > > yet in the CPU cache(s). That causes quite significant stalls due= to > memory > > > > > latency. Current implementation tries to migitate it using SW pip= eline > and > > > > SW > > > > > prefetch techniques, but stalls are still present. > > > > > Rework rte_sched_port_enqueue() to do actual fetch of all mbufs > > > > metadata > > > > > as a first stage of that function. > > > > > That helps to minimise load stalls at further stages of enqueue()= and > > > > > improves overall enqueue performance. > > > > > With examples/qos_sched I observed: > > > > > on ICX box: up to 30% cycles reduction > > > > > on CSX AND BDX: 20-15% cycles reduction > > > > > I also run tests with mbufs already in the cache (one core doing = RX, > QOS > > > > and > > > > > TX). > > > > > With such scenario, on all mentioned above IA boxes no performanc= e > drop > > > > > was observed. > > > > > > > > > > Signed-off-by: Konstantin Ananyev > > > > > --- > > > > > v2: fix clang and checkpatch complains > > > > > --- > > > > > lib/librte_sched/rte_sched.c | 219 +++++------------------------= ------ > > > > > 1 file changed, 31 insertions(+), 188 deletions(-) > > > > > > > > > > diff --git a/lib/librte_sched/rte_sched.c > b/lib/librte_sched/rte_sched.c > > > > index > > > > > 7c5688068..41ef147e0 100644 > > > > > --- a/lib/librte_sched/rte_sched.c > > > > > +++ b/lib/librte_sched/rte_sched.c > > > > > @@ -1861,24 +1861,23 @@ debug_check_queue_slab(struct > > > > > rte_sched_subport *subport, uint32_t bmp_pos, #endif /* > > > > > RTE_SCHED_DEBUG */ > > > > > > > > > > static inline struct rte_sched_subport * - > rte_sched_port_subport(struct > > > > > rte_sched_port *port, > > > > > - struct rte_mbuf *pkt) > > > > > +sched_port_subport(const struct rte_sched_port *port, struct > > > > > +rte_mbuf_sched sch) > > > > > { > > > > > - uint32_t queue_id =3D rte_mbuf_sched_queue_get(pkt); > > > > > + uint32_t queue_id =3D sch.queue_id; > > > > > uint32_t subport_id =3D queue_id >> (port- > > > > > >n_pipes_per_subport_log2 + 4); > > > > > > > > > > return port->subports[subport_id]; > > > > > } > > > > > > > > > > static inline uint32_t > > > > > -rte_sched_port_enqueue_qptrs_prefetch0(struct > rte_sched_subport > > > > > *subport, > > > > > - struct rte_mbuf *pkt, uint32_t subport_qmask) > > > > > +sched_port_enqueue_qptrs_prefetch0(const struct > rte_sched_subport > > > > > *subport, > > > > > + struct rte_mbuf_sched sch, uint32_t subport_qmask) > > > > > { > > > > > struct rte_sched_queue *q; > > > > > #ifdef RTE_SCHED_COLLECT_STATS > > > > > struct rte_sched_queue_extra *qe; > > > > > #endif > > > > > - uint32_t qindex =3D rte_mbuf_sched_queue_get(pkt); > > > > > + uint32_t qindex =3D sch.queue_id; > > > > > uint32_t subport_queue_id =3D subport_qmask & qindex; > > > > > > > > > > q =3D subport->queue + subport_queue_id; @@ -1971,197 > +1970,41 > > > > > @@ int rte_sched_port_enqueue(struct rte_sched_port *port, > struct > > > > > rte_mbuf **pkts, > > > > > uint32_t n_pkts) > > > > > { > > > > > - struct rte_mbuf *pkt00, *pkt01, *pkt10, *pkt11, *pkt20, > *pkt21, > > > > > - *pkt30, *pkt31, *pkt_last; > > > > > - struct rte_mbuf **q00_base, **q01_base, **q10_base, > > > > > **q11_base, > > > > > - **q20_base, **q21_base, **q30_base, **q31_base, > > > > > **q_last_base; > > > > > - struct rte_sched_subport *subport00, *subport01, > *subport10, > > > > > *subport11, > > > > > - *subport20, *subport21, *subport30, *subport31, > > > > > *subport_last; > > > > > - uint32_t q00, q01, q10, q11, q20, q21, q30, q31, q_last; > > > > > - uint32_t r00, r01, r10, r11, r20, r21, r30, r31, r_last; > > > > > - uint32_t subport_qmask; > > > > > uint32_t result, i; > > > > > + struct rte_mbuf_sched sch[n_pkts]; > > > > > + struct rte_sched_subport *subports[n_pkts]; > > > > > + struct rte_mbuf **q_base[n_pkts]; > > > > > + uint32_t q[n_pkts]; > > > > > + > > > > > + const uint32_t subport_qmask =3D > > > > > + (1 << (port->n_pipes_per_subport_log2 + 4)) - 1; > > > > > > > > > > result =3D 0; > > > > > - subport_qmask =3D (1 << (port->n_pipes_per_subport_log2 + > 4)) - 1; > > > > > > > > > > - /* > > > > > - * Less then 6 input packets available, which is not enough to > > > > > - * feed the pipeline > > > > > - */ > > > > > - if (unlikely(n_pkts < 6)) { > > > > > - struct rte_sched_subport *subports[5]; > > > > > - struct rte_mbuf **q_base[5]; > > > > > - uint32_t q[5]; > > > > > - > > > > > - /* Prefetch the mbuf structure of each packet */ > > > > > - for (i =3D 0; i < n_pkts; i++) > > > > > - rte_prefetch0(pkts[i]); > > > > > - > > > > > - /* Prefetch the subport structure for each packet */ > > > > > - for (i =3D 0; i < n_pkts; i++) > > > > > - subports[i] =3D rte_sched_port_subport(port, > pkts[i]); > > > > > - > > > > > - /* Prefetch the queue structure for each queue */ > > > > > - for (i =3D 0; i < n_pkts; i++) > > > > > - q[i] =3D > > > > > rte_sched_port_enqueue_qptrs_prefetch0(subports[i], > > > > > - pkts[i], subport_qmask); > > > > > - > > > > > - /* Prefetch the write pointer location of each queue > */ > > > > > - for (i =3D 0; i < n_pkts; i++) { > > > > > - q_base[i] =3D > > > > > rte_sched_subport_pipe_qbase(subports[i], q[i]); > > > > > - > rte_sched_port_enqueue_qwa_prefetch0(port, > > > > > subports[i], > > > > > - q[i], q_base[i]); > > > > > - } > > > > > + /* Prefetch the mbuf structure of each packet */ > > > > > + for (i =3D 0; i < n_pkts; i++) > > > > > + sch[i] =3D pkts[i]->hash.sched; > > > > > > > > > > > > > Hi Konstantin, thanks for the patch. In above case, all packets ar= e > touched > > > > straight with any prefetch. If we consider the input burst size of = 64 pkts, > it > > > > means 512 bytes of packet addresses (8 cache-lines) which is likel= y to > be > > > > available in cache. For larger size burst, e.g. 128 or 256, there m= ight be > > > > instances when some addresses are not available the cache, may stal= l > core. > > > > How about adding explicit prefetch before starting to iterate throu= gh > the > > > > packets if that helps? > > > > I don't think we need any prefetch here. > > pkts[] is a sequential array, HW prefetcher should be able to do good j= ob > here. > > Again in majority of use-cases pkts[] contents will already present in = the > cache. > > Though there is a valid concern here: n_pkts can be big, in that case w= e > probably > > don't want to store too much on the stack and read too much from pkts[]= . > > It is better to work in some fixed chunks (64 or so). > > I can prepare v2 with these changes, if there still is an interest in t= his patch. > > > > > Exactly. Konstantin, you might not be a fan of prefetches, but the cu= rrent > enqueue implementation (as well as the dequeue) uses a prefetch > > > state machine. Please keep the prefetch state machine in the scalar c= ode. > > > > It is not about our own preferences. > > From my measurements new version is faster and it is definitely simpler= . > > > > > Even if the examples/qos_sched might not show an advantage, > > > this is just a sample app and there are some more relevant use-cases = as > well. > > > > Well, I hope that examples/qos_sched reflects at least some real-world > use-cases for QOS library. > > Otherwise why do we have it inside DPDK codebase? > > About 'more relevant use-cases': if you do know such, can you try them > with the patch? > > I would really appreciate that. > > In fact, it is an ask not only to Cristian, but to all other interested= parties: > > if your app does use librte_sched - please try this patch and provide t= he > feedback. > > If some tests would flag a regression - I am absolutely ok to drop the = patch. > > Konstantin >=20 >=20 >=20 Hi Thomas, We are not going ahead with this at this moment.=20 Regards, Cristian