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 C6F77A0C41; Wed, 12 May 2021 17:33:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8D6B54003F; Wed, 12 May 2021 17:33:25 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 5C8E74003E for ; Wed, 12 May 2021 17:33:22 +0200 (CEST) IronPort-SDR: S3cemJXIy237uHYI0CmWZpo//DtPLVW7RL5g5QLE5u5XgPm0V+KCgzwdEPErlGZ8IyQcw++0nd dRHifx3zySVQ== X-IronPort-AV: E=McAfee;i="6200,9189,9982"; a="220710025" X-IronPort-AV: E=Sophos;i="5.82,293,1613462400"; d="scan'208";a="220710025" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 May 2021 08:32:55 -0700 IronPort-SDR: Qj8YBhJ9kyt8vGVViyFXJxqd3nbI0CdLttCTPLikNJb/W7Ga1GCkNrakzbgzrDDUVBY99IzjWW k2Whtcmh4Mzg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,293,1613462400"; d="scan'208";a="392790539" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga006.jf.intel.com with ESMTP; 12 May 2021 08:32:54 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 12 May 2021 08:32:54 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Wed, 12 May 2021 08:32:54 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.44) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Wed, 12 May 2021 08:32:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l8vMz+v8/Qi9rvVb3/F95MK/+3wToGp3zKTYFPvRDL4GTpl2RAYMj/8tfllGmqt8d07wqHyY8w3SsHhILStksuw4uknWviYTTGkou8rKh9TXCYMc0o5TpoIwUAKw28MRBfFr+Nm74KX48VJ/1ea87chUoJ+UXG1jdaT1zg26+7Qa4g3AAbGa0DBmVR6DRULaixV89keMdMnuVbcVrGSwbo0S/QVgK64lf95TQiXErNPYjEWc3sIHuw4bM3gcVnUv+ctiYxTEZR6nfQM7DBD3icTYxlBzwymFI3ncigbQPRCPzB0b4Uu/KZIZHU0e/sXpbBV8rYSI0rGOCgig3olagQ== 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-SenderADCheck; bh=gD/Gpu4Ie9HssR0l+TzkXS7FijIpARlQwi5xBe556H8=; b=i8eY2VSZfy1ZtP38+IjQDOacGrLZl+C808lSK+Iauz4yoPO2Xu2NP4BM5q7E2XmbFI+UOQbveXOEqGZvQcFu6wOfuiyW3OT9yObtzyCMTFwln8z41ePtYhL1H2g7sRgOcovtL7T5jrjRzW2djOpxYVgtscnWOlrIIxrch48z3IU0YnKFeDA6znSUwCp6RV4/IQA4j5GBE9xvTH4ybQK21T+AMJ/P+lWah3v/aN2m6XPrlIzBjKzIGaU+sr9oFt4F9XRwPSSZdXoG3ZM3t0/GJAfE39mzE6ev3IbWv1OED9W0iMfPXfLAh38gd25K8X+ivkGYt8C60OE1usR+DlMB7A== 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=gD/Gpu4Ie9HssR0l+TzkXS7FijIpARlQwi5xBe556H8=; b=TuW+h+eJ7cBWJMI7rE5mTz+mlT1rLUwezaarzsqMvpbPhlWbQlk58OgJbpRHLHYTObdZP9ki1L85HQlTpV38ARfvzgXVM0jUfO5iyGyhwOZEAUPXOGBt2+5ALUiuBrOVs1UKL8yf2hmLVHjD/1GxTwb3ig0b8Bdold2mDlXOf2s= Received: from MWHPR11MB1471.namprd11.prod.outlook.com (2603:10b6:301:b::13) by MWHPR1101MB2174.namprd11.prod.outlook.com (2603:10b6:301:50::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.25; Wed, 12 May 2021 15:32:52 +0000 Received: from MWHPR11MB1471.namprd11.prod.outlook.com ([fe80::4d84:659c:a4:8447]) by MWHPR11MB1471.namprd11.prod.outlook.com ([fe80::4d84:659c:a4:8447%10]) with mapi id 15.20.4129.025; Wed, 12 May 2021 15:32:52 +0000 From: "Dharmappa, Savinay" To: "dev@dpdk.org" Thread-Topic: dev Digest, Vol 348, Issue 163 Thread-Index: AQHXODAaZ6oikj1mAkyldUujCeOev6rgF3OQ Date: Wed, 12 May 2021 15:32:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.5.1.3 dlp-product: dlpe-windows authentication-results: dpdk.org; dkim=none (message not signed) header.d=none;dpdk.org; dmarc=none action=none header.from=intel.com; x-originating-ip: [122.167.177.114] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: baa9e7bc-67c1-4ed1-dadf-08d9155b34b5 x-ms-traffictypediagnostic: MWHPR1101MB2174: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: M1Z3cpX+3pcpuqUjQecSE3eDr+D7CSXSTlRw3tt5L/jTRCl860RiBJGLahxu2D2i0wp/6goV81LB6snKKYSQabT6C7AEuICVRsp1zgRyflrXurBVjVXVHwEeRXZ/AHC+ztDuIeeqgs0gNd6/moAiphVpsXdH0462QP7amHJ7n3VojY+ez+LQdLdPL0GFmZCG7valql/vsSYYSmhzJwWB/XdavUDmdqCnRnrLq+eBJaqbvthit/ALQf0JOuTyqE2dMxyaJBDGTv/NWGZcCeOi8hpxqtsVH78uFTT8ojnT8Nj1+SbBrOOunYFaMLUrtuKCnLeSt5A+aUHDIxPiJJjsCnVy9HxsXu+0oKkjkbyexzY/ThmvVbDDxn0GByldOryWHQh6Bm0M8l8kw3oXYnnRDmv3JvC5KygqlPZGroFuLPanOPUZru9S28y7kKMGhKP4Ik9qzqOUwyskQz0zwFv81AMqH+Di4gYn3pr3inOq2kS/7Vb7FfSgZd8buJG87uRvqvPoGfSGZaIzRh/3iX5t7pyPsEmsTG3LMtXGzHojCUhCLdHhJQsXFjBrBtMDY/cW1+GJws0LfwAbduIwfwABYSIld/B5R9Lf0PIpHB5lONFnYC6G5k/gRZh5ziS7gp3ORtkfs7pDF+X4p/Q27WBUlGBpSo+0MMNecUfmqHjeVGowTH699AXCg9R8/PTOrv0J x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1471.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(396003)(136003)(366004)(346002)(86362001)(2906002)(66476007)(66946007)(8676002)(83380400001)(33656002)(66446008)(71200400001)(66556008)(76116006)(64756008)(55016002)(8936002)(38100700002)(9686003)(478600001)(5660300002)(6506007)(53546011)(122000001)(7696005)(30864003)(6916009)(26005)(186003)(966005)(52536014)(316002)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Tl+jIhOA8C1AqcuVBwR2NHPWsPkJj+1NBxD8ycCu11triZ2UPpobjdrHsInP?= =?us-ascii?Q?nGj/7DXWDckZVovvRdbLWHWMlyjqh76n5VQSsUPQmNM+9dWpMXNjHW30JFPx?= =?us-ascii?Q?PzzDWAurV0nCVjkl/CD22pLY6/jsMjM3KZi+5CSyDAuzXc3fEfKnJ7/oebyI?= =?us-ascii?Q?eAlGrFbKim7PF34ghsrOYz4E5c20kKghYwjLAcSM6dvn1ipO3lL8s9A0u2ee?= =?us-ascii?Q?H+t0WLsiEc2s90qa7znVSVAdBYlEVmAFgoc9M235f3nZMfaVNRdCXE2TLAAc?= =?us-ascii?Q?drEQcAS+q32K1Lx7VPhVxuldXs6+zPubVdqv+mAvL+b6t62BaB8iirlumf9v?= =?us-ascii?Q?KYKP56HZIxy8n+OrhzvbE6qwHts7iKvkU2PNFUSVF9nQ4/3vQwcqMapOdQ4b?= =?us-ascii?Q?B/eJ+NiYvTgaK5GgYLEmHcaTSKlhdpTnWvwxDPlb72WTvZgi4qwlXTA8zEex?= =?us-ascii?Q?8dBZf4ji6ddalXkIINXWr6qxMK0OJg0f4BwKh/r2QIJv4mgb32id353QL6oZ?= =?us-ascii?Q?woJD6BpZnOqA95lJMSVrxYt2M67UK04WUTGt85tcHFEeyLuOy7qmq/zYpBJy?= =?us-ascii?Q?XH4dSFHSWLFS4eCUGOhQufC8P1YdEtGzVKU/bU03TU+fvYddXyAJ94KydDWp?= =?us-ascii?Q?10M9UV9F0AD1nRpD8756R/I6g2pKn1AnB+NQAlEeoOeXbK6yydTjREWrMIZ7?= =?us-ascii?Q?tNserVR70VLO7YhLtu+rWWQFN8C4B1sgwcBQ0AVOw+nVdj/TplUxAFT9VcYZ?= =?us-ascii?Q?2zdXshZZlmXg/gsZJl1vWggPE3WarU8ibl8MZotIDTOM8cflSGDOk3Q0/ad1?= =?us-ascii?Q?UPUteZENMgQ3RJ38a8iyovSN0liuYkDdXY91hqPf9en5L/iGGqPofMbd6Twz?= =?us-ascii?Q?1CCGQjtbbufIGwvDjYUK9UF94uIKjyNZX3+Ggj/xPmKeNBzv6Id2V88F3IM1?= =?us-ascii?Q?nidNcfMHmERkp1ujjQpuP78a3kUScdAXDB8jU457YOgsfSqZvbm7coSEZfL0?= =?us-ascii?Q?aNWijjjVKDYv4Ef2o7oSC20EPvD0Vr+ptoRY4T53MN1k0VMhdqb+8Os7G+aH?= =?us-ascii?Q?0t8axGbTVwJpee/zJ6GfnlUzeOLlWjjUS7vmIYtU0Y8LJxJNI6GyggaEARFA?= =?us-ascii?Q?mt+jAVzpffZmtKDU3YQqnUYhpruE4z4GooSd+MtNBCT4B4yfXAJO8i1Pr4ZJ?= =?us-ascii?Q?sZpTwKkTnc8352bj+OU0xJyqGH9vCpplcPObaAZe7y8PSw0T9fDQaf9nGSNq?= =?us-ascii?Q?6iNne2iVxFg/0qoL8jnjIGAKyjmNBJ0rKIT16C8RbpfFM6rYLTiFd+Y2RFzQ?= =?us-ascii?Q?k+7L2cItcZAJOVipf9wIYUKB?= x-ms-exchange-transport-forked: True 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: MWHPR11MB1471.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: baa9e7bc-67c1-4ed1-dadf-08d9155b34b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2021 15:32:51.9196 (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: WgeUELAvZrZPVND9oNiaFTexEVQ7eXysxBgog8BYr97t8tXxnvcYfylrnI9P3cxwMmlVY/9az+mdmvqyoToVJZQiRxeyZycx+BBVTuPIhfo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2174 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] dev Digest, Vol 348, Issue 163 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 Sender: "dev" -----Original Message----- From: dev On Behalf Of dev-request@dpdk.org Sent: Friday, April 23, 2021 4:31 PM To: dev@dpdk.org Subject: dev Digest, Vol 348, Issue 163 Send dev mailing list submissions to dev@dpdk.org To subscribe or unsubscribe via the World Wide Web, visit https://mails.dpdk.org/listinfo/dev or, via email, send a message with subject or body 'help' to dev-request@dpdk.org You can reach the person managing the list at dev-owner@dpdk.org When replying, please edit your Subject line so it is more specific than "R= e: Contents of dev digest..." Today's Topics: 1. Re: [PATCH] net/kni: check rte kni init result (Ferruh Yigit) 2. Re: [PATCH v3 2/2] lib/mempool: distinguish debug counters from cache and pool (Kinsella, Ray) 3. Re: [PATCH v2 1/3] bus/pci: enable PCI master in command register (Kinsella, Ray) 4. Re: [PATCH] doc: announce modification in eventdev structure (Kinsella, Ray) 5. [PATCH 0/2] bugfix for sched (Min Hu (Connor)) 6. [PATCH 1/2] lib/sched: fix return value judgment (Min Hu (Connor)) 7. [PATCH 2/2] lib/sched: optimize exception handling code (Min Hu (Connor)) ---------------------------------------------------------------------- Message: 1 Date: Fri, 23 Apr 2021 11:17:07 +0100 From: Ferruh Yigit To: "Min Hu (Connor)" , dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] net/kni: check rte kni init result Message-ID: <287cdaba-f3b8-141d-7b55-22ac09fa1f13@intel.com> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed On 4/21/2021 3:14 AM, Min Hu (Connor) wrote: > From: Chengwen Feng >=20 > This patch adds checking for rte_kni_init() result. >=20 > Fixes: 75e2bc54c018 ("net/kni: add KNI PMD") > Cc: stable@dpdk.org >=20 > Signed-off-by: Chengwen Feng > Signed-off-by: Min Hu (Connor) Acked-by: Ferruh Yigit ------------------------------ Message: 2 Date: Fri, 23 Apr 2021 11:41:39 +0100 From: "Kinsella, Ray" To: Olivier Matz , Dharmik Thakkar Cc: Andrew Rybchenko , dev@dpdk.org, nd@arm.com, joyce.kong@arm.com Subject: Re: [dpdk-dev] [PATCH v3 2/2] lib/mempool: distinguish debug counters from cache and pool Message-ID: Content-Type: text/plain; charset=3Dutf-8 On 21/04/2021 17:29, Olivier Matz wrote: > Hi Dharmik, >=20 > Please see some comments below. >=20 > On Mon, Apr 19, 2021 at 07:08:00PM -0500, Dharmik Thakkar wrote: >> From: Joyce Kong >> >> If cache is enabled, objects will be retrieved/put from/to cache,=20 >> subsequently from/to the common pool. Now the debug stats calculate=20 >> the objects retrieved/put from/to cache and pool together, it is=20 >> better to distinguish them. >> >> Signed-off-by: Joyce Kong >> Signed-off-by: Dharmik Thakkar >> Reviewed-by: Ruifeng Wang >> Reviewed-by: Honnappa Nagarahalli >> --- >> lib/librte_mempool/rte_mempool.c | 24 ++++++++++++++++ =20 >> lib/librte_mempool/rte_mempool.h | 47=20 >> ++++++++++++++++++++++---------- >> 2 files changed, 57 insertions(+), 14 deletions(-) >> >> diff --git a/lib/librte_mempool/rte_mempool.c=20 >> b/lib/librte_mempool/rte_mempool.c >> index afb1239c8d48..339f14455624 100644 >> --- a/lib/librte_mempool/rte_mempool.c >> +++ b/lib/librte_mempool/rte_mempool.c >> @@ -1244,6 +1244,18 @@ rte_mempool_dump(FILE *f, struct rte_mempool *mp) >> for (lcore_id =3D 0; lcore_id < RTE_MAX_LCORE; lcore_id++) { >> sum.put_bulk +=3D mp->stats[lcore_id].put_bulk; >> sum.put_objs +=3D mp->stats[lcore_id].put_objs; >> + sum.put_common_pool_bulk +=3D >> + mp->stats[lcore_id].put_common_pool_bulk; >> + sum.put_common_pool_objs +=3D >> + mp->stats[lcore_id].put_common_pool_objs; >> + sum.put_cache_bulk +=3D mp->stats[lcore_id].put_cache_bulk; >> + sum.put_cache_objs +=3D mp->stats[lcore_id].put_cache_objs; >> + sum.get_common_pool_bulk +=3D >> + mp->stats[lcore_id].get_common_pool_bulk; >> + sum.get_common_pool_objs +=3D >> + mp->stats[lcore_id].get_common_pool_objs; >> + sum.get_cache_bulk +=3D mp->stats[lcore_id].get_cache_bulk; >> + sum.get_cache_objs +=3D mp->stats[lcore_id].get_cache_objs; >> sum.get_success_bulk +=3D mp->stats[lcore_id].get_success_bulk; >> sum.get_success_objs +=3D mp->stats[lcore_id].get_success_objs; >> sum.get_fail_bulk +=3D mp->stats[lcore_id].get_fail_bulk; >> @@ -1254,6 +1266,18 @@ rte_mempool_dump(FILE *f, struct rte_mempool *mp) >> fprintf(f, " stats:\n"); >> fprintf(f, " put_bulk=3D%"PRIu64"\n", sum.put_bulk); >> fprintf(f, " put_objs=3D%"PRIu64"\n", sum.put_objs); >> + fprintf(f, " put_common_pool_bulk=3D%"PRIu64"\n", >> + sum.put_common_pool_bulk); >> + fprintf(f, " put_common_pool_objs=3D%"PRIu64"\n", >> + sum.put_common_pool_objs); >> + fprintf(f, " put_cache_bulk=3D%"PRIu64"\n", sum.put_cache_bulk); >> + fprintf(f, " put_cache_objs=3D%"PRIu64"\n", sum.put_cache_objs); >> + fprintf(f, " get_common_pool_bulk=3D%"PRIu64"\n", >> + sum.get_common_pool_bulk); >> + fprintf(f, " get_common_pool_objs=3D%"PRIu64"\n", >> + sum.get_common_pool_objs); >> + fprintf(f, " get_cache_bulk=3D%"PRIu64"\n", sum.get_cache_bulk); >> + fprintf(f, " get_cache_objs=3D%"PRIu64"\n", sum.get_cache_objs); >> fprintf(f, " get_success_bulk=3D%"PRIu64"\n", sum.get_success_bulk)= ; >> fprintf(f, " get_success_objs=3D%"PRIu64"\n", sum.get_success_objs)= ; >> fprintf(f, " get_fail_bulk=3D%"PRIu64"\n", sum.get_fail_bulk); >> diff --git a/lib/librte_mempool/rte_mempool.h=20 >> b/lib/librte_mempool/rte_mempool.h >> index 848a19226149..0959f8a3f367 100644 >> --- a/lib/librte_mempool/rte_mempool.h >> +++ b/lib/librte_mempool/rte_mempool.h >> @@ -66,12 +66,20 @@ extern "C" { >> * A structure that stores the mempool statistics (per-lcore). >> */ >> struct rte_mempool_debug_stats { >> - uint64_t put_bulk; /**< Number of puts. */ >> - uint64_t put_objs; /**< Number of objects successfully put. */ >> - uint64_t get_success_bulk; /**< Successful allocation number. */ >> - uint64_t get_success_objs; /**< Objects successfully allocated. */ >> - uint64_t get_fail_bulk; /**< Failed allocation number. */ >> - uint64_t get_fail_objs; /**< Objects that failed to be allocated. *= / >> + uint64_t put_bulk; /**< Number of puts. */ >> + uint64_t put_objs; /**< Number of objects successfully put. */ >> + uint64_t put_common_pool_bulk; /**< Number of bulks enqueued in comm= on pool. */ >> + uint64_t put_common_pool_objs; /**< Number of objects enqueued in co= mmon pool. */ >> + uint64_t put_cache_bulk; /**< Number of bulks enqueued in cache. */ >> + uint64_t put_cache_objs; /**< Number of objects enqueued in cache. *= / >> + uint64_t get_common_pool_bulk; /**< Number of bulks dequeued from c= ommon pool. */ >> + uint64_t get_common_pool_objs; /**< Number of objects dequeued from = common pool. */ >> + uint64_t get_cache_bulk; /**< Number of bulks dequeued from cache. *= / >> + uint64_t get_cache_objs; /**< Number of objects dequeued from cache.= */ >> + uint64_t get_success_bulk; /**< Successful allocation number. */ >> + uint64_t get_success_objs; /**< Objects successfully allocated. */ >> + uint64_t get_fail_bulk; /**< Failed allocation number. */ >> + uint64_t get_fail_objs; /**< Objects that failed to be allocated. *= / >=20 > I missed it the first time, but this changes the size of the=20 > rte_mempool_debug_stats structure. I think we don't care about this=20 > ABI breakage because this structure is only defined if=20 > RTE_LIBRTE_MEMPOOL_DEBUG is set. But just in case, adding Ray as Cc. Agreed, if it is just a debugging non-default feature.=20 > About the field themselves, I'm not certain that there is an added=20 > value to have stats for cache gets and puts. My feeling is that the=20 > important stat to monitor is the access to common pool, because it is=20 > the one that highlights a possible performance impact (contention).=20 > The cache stats are more or less equal to "success + fail - common".=20 > Moreover, it will simplify the patch and avoid risks of mistakes. >=20 > What do you think? >=20 >> /** Successful allocation number of contiguous blocks. */ >> uint64_t get_success_blks; >> /** Failed allocation number of contiguous blocks. */ @@ -699,10=20 >> +707,18 @@ rte_mempool_ops_dequeue_bulk(struct rte_mempool *mp, >> void **obj_table, unsigned n) >> { >> struct rte_mempool_ops *ops; >> + int ret; >> =20 >> rte_mempool_trace_ops_dequeue_bulk(mp, obj_table, n); >> ops =3D rte_mempool_get_ops(mp->ops_index); >> - return ops->dequeue(mp, obj_table, n); >> + ret =3D ops->dequeue(mp, obj_table, n); >> + if (ret =3D=3D 0) { >> + __MEMPOOL_STAT_ADD(mp, get_common_pool_bulk, 1); >> + __MEMPOOL_STAT_ADD(mp, get_common_pool_objs, n); >> + __MEMPOOL_STAT_ADD(mp, get_success_bulk, 1); >> + __MEMPOOL_STAT_ADD(mp, get_success_objs, n); >> + } >> + return ret; >> } >> =20 >> /** >> @@ -749,6 +765,8 @@ rte_mempool_ops_enqueue_bulk(struct rte_mempool=20 >> *mp, void * const *obj_table, { >> struct rte_mempool_ops *ops; >> =20 >> + __MEMPOOL_STAT_ADD(mp, put_common_pool_bulk, 1); >> + __MEMPOOL_STAT_ADD(mp, put_common_pool_objs, n); >> rte_mempool_trace_ops_enqueue_bulk(mp, obj_table, n); >> ops =3D rte_mempool_get_ops(mp->ops_index); >> return ops->enqueue(mp, obj_table, n); @@ -1297,14 +1315,18 @@=20 >> __mempool_generic_put(struct rte_mempool *mp, void * const=20 >> *obj_table, >> =20 >> /* Add elements back into the cache */ >> rte_memcpy(&cache_objs[0], obj_table, sizeof(void *) * n); >> - >> cache->len +=3D n; >> =20 >> + __MEMPOOL_STAT_ADD(mp, put_cache_bulk, 1); >> + >> if (cache->len >=3D cache->flushthresh) { >> + __MEMPOOL_STAT_ADD(mp, put_cache_objs, >> + n - (cache->len - cache->size)); >> rte_mempool_ops_enqueue_bulk(mp, &cache->objs[cache->size], >> cache->len - cache->size); >> cache->len =3D cache->size; >> - } >> + } else >> + __MEMPOOL_STAT_ADD(mp, put_cache_objs, n); >> =20 >=20 > In case we keep cache stats, I'd add {} after the else to be=20 > consistent with the if(). >=20 >> return; >> =20 >> @@ -1438,8 +1460,8 @@ __mempool_generic_get(struct rte_mempool *mp,=20 >> void **obj_table, >> =20 >> cache->len -=3D n; >> =20 >> - __MEMPOOL_STAT_ADD(mp, get_success_bulk, 1); >> - __MEMPOOL_STAT_ADD(mp, get_success_objs, n); >> + __MEMPOOL_STAT_ADD(mp, get_cache_bulk, 1); >> + __MEMPOOL_STAT_ADD(mp, get_cache_objs, n); >=20 > In case we keep cache stats, I don't think we should remove=20 > get_success stats increment. Else, the success stats will never be=20 > incremented when retrieving objects from the cache. >=20 >=20 >> =20 >> return 0; >> =20 >> @@ -1451,9 +1473,6 @@ __mempool_generic_get(struct rte_mempool *mp, void= **obj_table, >> if (ret < 0) { >> __MEMPOOL_STAT_ADD(mp, get_fail_bulk, 1); >> __MEMPOOL_STAT_ADD(mp, get_fail_objs, n); >> - } else { >> - __MEMPOOL_STAT_ADD(mp, get_success_bulk, 1); >> - __MEMPOOL_STAT_ADD(mp, get_success_objs, n); >> } >> =20 >> return ret; >> -- >> 2.17.1 >> ------------------------------ Message: 3 Date: Fri, 23 Apr 2021 11:43:58 +0100 From: "Kinsella, Ray" To: Haiyue Wang , dev@dpdk.org Cc: qi.z.zhang@intel.com, liang-min.wang@intel.com, Neil Horman , Gaetan Rivet Subject: Re: [dpdk-dev] [PATCH v2 1/3] bus/pci: enable PCI master in command register Message-ID: <1c9d285c-81c6-a977-682a-473e691abda0@ashroe.eu> Content-Type: text/plain; charset=3Dutf-8 On 22/04/2021 02:18, Haiyue Wang wrote: > This adds the support to set 'Bus Master Enable' bit in the PCI command > register. >=20 > Signed-off-by: Haiyue Wang > Tested-by: Qi Zhang > --- > drivers/bus/pci/pci_common.c | 20 ++++++++++++++++++++ > drivers/bus/pci/rte_bus_pci.h | 12 ++++++++++++ > drivers/bus/pci/version.map | 1 + > lib/pci/rte_pci.h | 4 ++++ > 4 files changed, 37 insertions(+) >=20 > diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c > index ee7f96635..b631cb9c7 100644 > --- a/drivers/bus/pci/pci_common.c > +++ b/drivers/bus/pci/pci_common.c > @@ -746,6 +746,26 @@ rte_pci_find_ext_capability(struct rte_pci_device *d= ev, uint32_t cap) > return 0; > } > =20 > +int > +rte_pci_enable_bus_master(struct rte_pci_device *dev) > +{ > + uint16_t cmd; > + > + if (rte_pci_read_config(dev, &cmd, sizeof(cmd), RTE_PCI_COMMAND) < 0) { > + RTE_LOG(ERR, EAL, "error in reading PCI command register\n"); > + return -1; > + } > + > + cmd |=3D RTE_PCI_COMMAND_MASTER; > + > + if (rte_pci_write_config(dev, &cmd, sizeof(cmd), RTE_PCI_COMMAND) < 0) = { > + RTE_LOG(ERR, EAL, "error in writing PCI command register\n"); > + return -1; > + } > + > + return 0; > +} > + > struct rte_pci_bus rte_pci_bus =3D { > .bus =3D { > .scan =3D rte_pci_scan, > diff --git a/drivers/bus/pci/rte_bus_pci.h b/drivers/bus/pci/rte_bus_pci.= h > index 64886b473..83caf477b 100644 > --- a/drivers/bus/pci/rte_bus_pci.h > +++ b/drivers/bus/pci/rte_bus_pci.h > @@ -249,6 +249,18 @@ void rte_pci_dump(FILE *f); > __rte_experimental > off_t rte_pci_find_ext_capability(struct rte_pci_device *dev, uint32_t c= ap); > =20 > +/** > + * Enables Bus Master for device's PCI command register. > + * > + * @param dev > + * A pointer to rte_pci_device structure. > + * > + * @return > + * 0 on success, -1 on error in PCI config space read/write. > + */ > +__rte_experimental > +int rte_pci_enable_bus_master(struct rte_pci_device *dev); > + > /** > * Register a PCI driver. > * > diff --git a/drivers/bus/pci/version.map b/drivers/bus/pci/version.map > index f33ed0abd..b271e48a8 100644 > --- a/drivers/bus/pci/version.map > +++ b/drivers/bus/pci/version.map > @@ -20,5 +20,6 @@ DPDK_21 { > EXPERIMENTAL { > global: > =20 Please annotate when the symbol was added. > + rte_pci_enable_bus_master; > rte_pci_find_ext_capability; > }; > diff --git a/lib/pci/rte_pci.h b/lib/pci/rte_pci.h > index a8f8e404a..1f33d687f 100644 > --- a/lib/pci/rte_pci.h > +++ b/lib/pci/rte_pci.h > @@ -32,6 +32,10 @@ extern "C" { > =20 > #define RTE_PCI_VENDOR_ID 0x00 /* 16 bits */ > #define RTE_PCI_DEVICE_ID 0x02 /* 16 bits */ > +#define RTE_PCI_COMMAND 0x04 /* 16 bits */ > + > +/* PCI Command Register */ > +#define RTE_PCI_COMMAND_MASTER 0x4 /* Bus Master Enable */ > =20 > /* PCI Express capability registers */ > #define RTE_PCI_EXP_DEVCTL 8 /* Device Control */ >=20 ------------------------------ Message: 4 Date: Fri, 23 Apr 2021 11:53:19 +0100 From: "Kinsella, Ray" To: gakhil@marvell.com, jerinj@marvell.com, thomas@monjalon.net, dev@dpdk.org, david.marchand@redhat.com Cc: abhinandan.gujjar@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, sachin.saxena@oss.nxp.com, anoobj@marvell.com, matan@nvidia.com, roy.fan.zhang@intel.com, g.singh@nxp.com, erik.g.carrillo@intel.com, jay.jayatheerthan@intel.com, pbhagavatula@marvell.com, harry.van.haaren@intel.com, sthotton@marvell.com Subject: Re: [dpdk-dev] [PATCH] doc: announce modification in eventdev structure Message-ID: <347ace77-7704-5ac4-7dd9-0cabe88dfce0@ashroe.eu> Content-Type: text/plain; charset=3Dutf-8 On 15/04/2021 10:08, gakhil@marvell.com wrote: > From: Akhil Goyal >=20 > A new field ``ca_enqueue`` is added in ``rte_eventdev`` > in the end to maintain ABI. It needs to be moved above > in the structure to align with other enqueue callbacks. >=20 > Signed-off-by: Akhil Goyal > --- > doc/guides/rel_notes/deprecation.rst | 4 ++++ > 1 file changed, 4 insertions(+) >=20 > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/= deprecation.rst > index 2afc84c39..a973de4a9 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -127,6 +127,10 @@ Deprecation Notices > values to the function ``rte_event_eth_rx_adapter_queue_add`` using > the structure ``rte_event_eth_rx_adapter_queue_add``. > =20 > +* eventdev: The function pointer ``ca_enqueue`` in structure ``rte_event= dev`` > + will be moved after ``txa_enqueue`` so that all enqueue/dequeue > + function pointers are adjacent to each other. > + > * sched: To allow more traffic classes, flexible mapping of pipe queues = to > traffic classes, and subport level configuration of pipes and queues > changes will be made to macros, data structures and API functions defi= ned >=20 I admire the disipline - but since you are not actually removing ca_enqueue= , just moving it in memory when the new ABI is declared in anycase, this is n= ot required. Thanks, Ray K ------------------------------ Message: 5 Date: Fri, 23 Apr 2021 19:01:10 +0800 From: "Min Hu (Connor)" To: Cc: , , Subject: [dpdk-dev] [PATCH 0/2] bugfix for sched Message-ID: <1619175672-20016-1-git-send-email-humin29@huawei.com> Content-Type: text/plain This patch set contains two bugfixes for sched. Huisong Li (2): lib/sched: fix return value judgment lib/sched: optimize exception handling code lib/sched/rte_sched.c | 60 +++++++++++++++++++++++++++--------------------= ---- 1 file changed, 32 insertions(+), 28 deletions(-) --=20 2.7.4 ------------------------------ Message: 6 Date: Fri, 23 Apr 2021 19:01:11 +0800 From: "Min Hu (Connor)" To: Cc: , , Subject: [dpdk-dev] [PATCH 1/2] lib/sched: fix return value judgment Message-ID: <1619175672-20016-2-git-send-email-humin29@huawei.com> Content-Type: text/plain From: Huisong Li This patch fixes return value judgment when allocate memory to store the subport profile, and releases memory of 'rte_sched_port' if code fails to apply for this memory. Fixes: 0ea4c6afcaf1 ("sched: add subport profile table") Cc: stable@dpdk.org Signed-off-by: Huisong Li Signed-off-by: Min Hu (Connor) --- lib/sched/rte_sched.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c index cd87e68..df0ab5c 100644 --- a/lib/sched/rte_sched.c +++ b/lib/sched/rte_sched.c @@ -961,9 +961,9 @@ rte_sched_port_config(struct rte_sched_port_params *par= ams) /* Allocate memory to store the subport profile */ port->subport_profiles =3D rte_zmalloc_socket("subport_profile", size2, RTE_CACHE_LINE_SIZE, params->socket); - if (port =3D=3D NULL) { + if (port->subport_profiles =3D=3D NULL) { RTE_LOG(ERR, SCHED, "%s: Memory allocation fails\n", __func__); - + rte_free(port); return NULL; } =20 --=20 2.7.4 Ack ------------------------------ Message: 7 Date: Fri, 23 Apr 2021 19:01:12 +0800 From: "Min Hu (Connor)" To: Cc: , , Subject: [dpdk-dev] [PATCH 2/2] lib/sched: optimize exception handling code Message-ID: <1619175672-20016-3-git-send-email-humin29@huawei.com> Content-Type: text/plain From: Huisong Li Currently, rte_sched_free_memory() is called multiple times by the exception handling code in rte_sched_subport_config() and rte_sched_pipe_config(). This patch optimizes them into a unified outlet to free memory. Fixes: ac6fcb841b0f ("sched: update subport rate dynamically") Fixes: 34a90f86657c ("sched: modify pipe functions for config flexibility") Fixes: ce7c4fd7c2ac ("sched: add pipe config to subport level") Cc: stable@dpdk.org Signed-off-by: Huisong Li Signed-off-by: Min Hu (Connor) --- lib/sched/rte_sched.c | 56 +++++++++++++++++++++++++++--------------------= ---- 1 file changed, 30 insertions(+), 26 deletions(-) diff --git a/lib/sched/rte_sched.c b/lib/sched/rte_sched.c index df0ab5c..a858f61 100644 --- a/lib/sched/rte_sched.c +++ b/lib/sched/rte_sched.c @@ -1090,6 +1090,7 @@ rte_sched_subport_config(struct rte_sched_port *port, uint32_t n_subport_pipe_queues, i; uint32_t size0, size1, bmp_mem_size; int status; + int ret; =20 /* Check user parameters */ if (port =3D=3D NULL) { @@ -1101,17 +1102,16 @@ rte_sched_subport_config(struct rte_sched_port *por= t, if (subport_id >=3D port->n_subports_per_port) { RTE_LOG(ERR, SCHED, "%s: Incorrect value for subport id\n", __func__); - - rte_sched_free_memory(port, n_subports); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 if (subport_profile_id >=3D port->n_max_subport_profiles) { RTE_LOG(ERR, SCHED, "%s: " "Number of subport profile exceeds the max limit\n", __func__); - rte_sched_free_memory(port, n_subports); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 /** Memory is allocated only on first invocation of the api for a @@ -1127,9 +1127,8 @@ rte_sched_subport_config(struct rte_sched_port *port, RTE_LOG(NOTICE, SCHED, "%s: Port scheduler params check failed (%d)\n", __func__, status); - - rte_sched_free_memory(port, n_subports); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 /* Determine the amount of memory to allocate */ @@ -1143,9 +1142,8 @@ rte_sched_subport_config(struct rte_sched_port *port, if (s =3D=3D NULL) { RTE_LOG(ERR, SCHED, "%s: Memory allocation fails\n", __func__); - - rte_sched_free_memory(port, n_subports); - return -ENOMEM; + ret =3D -ENOMEM; + goto out; } =20 n_subports++; @@ -1185,12 +1183,11 @@ rte_sched_subport_config(struct rte_sched_port *por= t, params->red_params[i][j].min_th, params->red_params[i][j].max_th, params->red_params[i][j].maxp_inv) !=3D 0) { - rte_sched_free_memory(port, n_subports); - RTE_LOG(NOTICE, SCHED, "%s: RED configuration init fails\n", __func__); - return -EINVAL; + ret =3D -EINVAL; + goto out; } } } @@ -1238,9 +1235,8 @@ rte_sched_subport_config(struct rte_sched_port *port, if (s->bmp =3D=3D NULL) { RTE_LOG(ERR, SCHED, "%s: Subport bitmap init error\n", __func__); - - rte_sched_free_memory(port, n_subports); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 for (i =3D 0; i < RTE_SCHED_PORT_N_GRINDERS; i++) @@ -1285,6 +1281,11 @@ rte_sched_subport_config(struct rte_sched_port *port= , rte_sched_port_log_subport_profile(port, subport_profile_id); =20 return 0; + +out: + rte_sched_free_memory(port, n_subports); + + return ret; } =20 int @@ -1299,6 +1300,7 @@ rte_sched_pipe_config(struct rte_sched_port *port, struct rte_sched_pipe_profile *params; uint32_t n_subports =3D subport_id + 1; uint32_t deactivate, profile, i; + int ret; =20 /* Check user parameters */ profile =3D (uint32_t) pipe_profile; @@ -1313,26 +1315,23 @@ rte_sched_pipe_config(struct rte_sched_port *port, if (subport_id >=3D port->n_subports_per_port) { RTE_LOG(ERR, SCHED, "%s: Incorrect value for parameter subport id\n", __func__); - - rte_sched_free_memory(port, n_subports); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 s =3D port->subports[subport_id]; if (pipe_id >=3D s->n_pipes_per_subport_enabled) { RTE_LOG(ERR, SCHED, "%s: Incorrect value for parameter pipe id\n", __func__); - - rte_sched_free_memory(port, n_subports); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 if (!deactivate && profile >=3D s->n_pipe_profiles) { RTE_LOG(ERR, SCHED, "%s: Incorrect value for parameter pipe profile\n", __func__); - - rte_sched_free_memory(port, n_subports); - return -EINVAL; + ret =3D -EINVAL; + goto out; } =20 sp =3D port->subport_profiles + s->profile; @@ -1406,6 +1405,11 @@ rte_sched_pipe_config(struct rte_sched_port *port, } =20 return 0; + +out: + rte_sched_free_memory(port, n_subports); + + return ret; } =20 int --=20 2.7.4 End of dev Digest, Vol 348, Issue 163 *************************************