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 C7826A052A; Fri, 10 Jul 2020 17:20:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2C171DA1C; Fri, 10 Jul 2020 17:20:16 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8EDE11DA19 for ; Fri, 10 Jul 2020 17:20:15 +0200 (CEST) IronPort-SDR: ejwzsODOa6JT+/ADrkk9dM1aiTrF1dvosRBW5axe9KocOKy98I9OUjzVd1yQ9+vhtLAy7iCjxZ 0YUdgQ9uzqUg== X-IronPort-AV: E=McAfee;i="6000,8403,9678"; a="149691470" X-IronPort-AV: E=Sophos;i="5.75,336,1589266800"; d="scan'208";a="149691470" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2020 08:20:14 -0700 IronPort-SDR: CMtTl+fdt8q5zRproSRijHNOtGZmmQHRwpVTDa95kXsDXxUgaoSm870ODAnKc62Gb6wJ/yP/8Y 2UB2KcwOou6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,336,1589266800"; d="scan'208";a="269113369" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga008.fm.intel.com with ESMTP; 10 Jul 2020 08:20:14 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 10 Jul 2020 08:20:14 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 10 Jul 2020 08:20:13 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.177) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 10 Jul 2020 08:20:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ljxOXuHbXpaznC5+PoB4RSvFOXyqyvC5oYr9vwLjemkFVCoBNzmdOKMuUUM9dm8LaOJ5qC50c0/GOWkdMEbh8tSVF1ksHR5pZAMP5k9Zh/+9QGJijPLR4Y8xogObM5EzvNc0nUCc5JRbEYVQgIC3g2DZLqpwFhXgRuf6/+aNvOLKyzqY/tCOC/cQWPnA0KmOfhQWkp49wd8RwPEDI/gS0b2lhpxjBA3LDdBz4aBnnRladc22xdWeusBHggx3cbQExKg/bJ9jv02aHuB/Q58sQOzDZHBb5ESGv1o8qEKfhxRxlA4T9RRvfLRfk5gIlvnNPEwLxtlnQYW0Qsls01g9/Q== 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=AUoEBQw2hYDEcBpm3kK/vEfBpotRYDaFuBtId2oy0pQ=; b=mQlQiMNx9QYdr5I8HseXEilaeiHWmfqdj979HYDhniDmW8lzXIJRRwdgVATnYXUFFZhFOThFxT2yAR2XeReKlEp4B+qMubl0fsJLxbKHBA7oG41Q9InnkhoWtl4owoCNW4AOf7ErtEGNJqervnLUkdUHjixy8mp1IxLnO9CPLEdVaHFXskvJ5eWP0rf1P0qR8Flhq8f9ITpm2dMoNx5WpoJUrd6TpAPtqGuYXgL7unEaAvCu1UXnxcslbE6headV6iQ8wFkMpEt87Uq0KxponpOXQBtcK/Br796iVmVu9gYMd9ykOl3Hf6XrC8MVkUcXjEmpjtsAZwGGy1Q6Dr8tpg== 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=AUoEBQw2hYDEcBpm3kK/vEfBpotRYDaFuBtId2oy0pQ=; b=RZKn0CooqE2ISoOSDIKbwOgwNHjrE+mVGNbTczK7x6o+bBe8QpN9/Aohj53NadVVuAodvn4uZgT6GOwdv8lmA50eGBFFkZA9JCF+eEvL8+2Nu9F18H2FVgRsMPYNxMHn7ZgaZ/mknvn9qFYMVegV7MuZ30/52WRpt6wIOxMDZFU= Received: from BYAPR11MB3301.namprd11.prod.outlook.com (2603:10b6:a03:7f::26) by BY5PR11MB4226.namprd11.prod.outlook.com (2603:10b6:a03:1bf::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Fri, 10 Jul 2020 15:20:12 +0000 Received: from BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::f160:29ab:b8f9:4189]) by BYAPR11MB3301.namprd11.prod.outlook.com ([fe80::f160:29ab:b8f9:4189%6]) with mapi id 15.20.3174.023; Fri, 10 Jul 2020 15:20:12 +0000 From: "Ananyev, Konstantin" To: Olivier Matz CC: "dev@dpdk.org" , "arybchenko@solarflare.com" , "jielong.zjl@antfin.com" , "Eads, Gage" Thread-Topic: [PATCH v2] mempool/ring: add support for new ring sync modes Thread-Index: AQHWTi/h8GtyGouqIUabQ46ZzlWz+aj/fMmAgAAHuBCAAVEngIAAJyIggAABBlA= Date: Fri, 10 Jul 2020 15:20:12 +0000 Message-ID: References: <20200521132027.28219-1-konstantin.ananyev@intel.com> <20200629161024.29059-1-konstantin.ananyev@intel.com> <20200709161829.GV5869@platinum> <20200710125249.GZ5869@platinum> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2NkYmNmNDAtMjdhNy00NzhhLThiODItM2UwMDE3ZGY0MTU0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieW1oODlPMXZhVW8xNDBWVnlzKzNMbWxVTXI1RHRYQU1tdEVxWVBMYnNkMlVGeWxETElobGNsMDhqMWxyenFIUSJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.151.177] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 417fe17b-36c5-40e2-2752-08d824e4bda8 x-ms-traffictypediagnostic: BY5PR11MB4226: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OclxbwSot8hanJaJT6LSznRTYuaBvRy5l4YOScrfT4GzbUZk3+464glO7CwVfw3TemSGlG5d6mNXGy+81mAlZSXt+lyqcIjdVb+B2S0MP+wn/+vhfFIs0FqN3Y8KnhIx4p/V1M1HQwm0nd3hTya2kG0Vbf8zSSR18gP6KQdes0AoKT6SDsUYXN+NPczAVWV0NgB9SoJyaWc90h0CxSBDR25vAxiko5xfI4bDiMmXoRsdLfzDVLiRencxMrweW52A/FMhYQb1obSi9XRpmNeMRxdUhHQVnSISXxdrjONwo9CgOMwYgzkNjyu8EOmgNrZiljdMOUsmVjnJGGd1P/ahWg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3301.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(39860400002)(366004)(136003)(346002)(7696005)(54906003)(66556008)(6506007)(55016002)(71200400001)(83380400001)(76116006)(66946007)(6916009)(64756008)(2940100002)(66476007)(8936002)(66446008)(186003)(52536014)(9686003)(26005)(8676002)(5660300002)(4326008)(316002)(33656002)(478600001)(2906002)(107886003)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: GdmnjUc2NRkm1zeD4AYAfgmlms6Qmoytrm6J7sIG9KOHwplUoMW2g3xEWse0LiN7WfWuf0F3N+eFm9I+uI//QMhauyvF40dDvuDt9tLQqLM4PYfxAFM9tT8dk0obuMpdNS4KYB8KFgOSLgWk9otUQXrsDdY/nwQx226vMSDwtodj5IHMRO40/nPWjU49hxkwi7YgFtX8P4WPzbJqpPerArln38x0QHjBPiDaLt2wfFzvsid68Fc8vrTptugD68fIDvGaO7QZvqQKOZn6ucgSV+IrN4eDEwWBXYVESyJZb9GdcSJIzioY2SGheRkQRIVZ+bgTg2bJH2RQF3ZgakLFulOKjbZl73+pxlZGfxtfqrn73M8s2quC1R/wUk2vlrh9SnkkZWq6G5rhX4QCku+kBFhSbV16c3ejhxiQojO33a9LC2PPcNeWJb5axuTJVEH8qfqshyj3PXTmO/wTk5D19Qbk5B0L5suTw2LdQi+jaLgORSZyB0MiS0ajtY5w5hRZ 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: BYAPR11MB3301.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 417fe17b-36c5-40e2-2752-08d824e4bda8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 15:20:12.3833 (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: BpT7I3H4Viwe+OWDvifMuHm60t1VULLyHoYa93fyrDjRT74Yey7GiNY8TmJut7HOmEKqTwySJAPHdcTbGUKLMcqQRc4OeJNauESwMrYPhTw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4226 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2] mempool/ring: add support for new ring sync modes 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" >=20 > Hi Olivier, >=20 > > Hi Konstantin, > > > > On Thu, Jul 09, 2020 at 05:55:30PM +0000, Ananyev, Konstantin wrote: > > > Hi Olivier, > > > > > > > Hi Konstantin, > > > > > > > > On Mon, Jun 29, 2020 at 05:10:24PM +0100, Konstantin Ananyev wrote: > > > > > v2: > > > > > - update Release Notes (as per comments) > > > > > > > > > > Two new sync modes were introduced into rte_ring: > > > > > relaxed tail sync (RTS) and head/tail sync (HTS). > > > > > This change provides user with ability to select these > > > > > modes for ring based mempool via mempool ops API. > > > > > > > > > > Signed-off-by: Konstantin Ananyev > > > > > Acked-by: Gage Eads > > > > > --- > > > > > doc/guides/rel_notes/release_20_08.rst | 6 ++ > > > > > drivers/mempool/ring/rte_mempool_ring.c | 97 +++++++++++++++++++= +++--- > > > > > 2 files changed, 94 insertions(+), 9 deletions(-) > > > > > > > > > > diff --git a/doc/guides/rel_notes/release_20_08.rst b/doc/guides/= rel_notes/release_20_08.rst > > > > > index eaaf11c37..7bdcf3aac 100644 > > > > > --- a/doc/guides/rel_notes/release_20_08.rst > > > > > +++ b/doc/guides/rel_notes/release_20_08.rst > > > > > @@ -84,6 +84,12 @@ New Features > > > > > * Dump ``rte_flow`` memory consumption. > > > > > * Measure packet per second forwarding. > > > > > > > > > > +* **Added support for new sync modes into mempool ring driver.** > > > > > + > > > > > + Added ability to select new ring synchronisation modes: > > > > > + ``relaxed tail sync (ring_mt_rts)`` and ``head/tail sync (ring= _mt_hts)`` > > > > > + via mempool ops API. > > > > > + > > > > > > > > > > Removed Items > > > > > ------------- > > > > > diff --git a/drivers/mempool/ring/rte_mempool_ring.c b/drivers/me= mpool/ring/rte_mempool_ring.c > > > > > index bc123fc52..15ec7dee7 100644 > > > > > --- a/drivers/mempool/ring/rte_mempool_ring.c > > > > > +++ b/drivers/mempool/ring/rte_mempool_ring.c > > > > > @@ -25,6 +25,22 @@ common_ring_sp_enqueue(struct rte_mempool *mp,= void * const *obj_table, > > > > > obj_table, n, NULL) =3D=3D 0 ? -ENOBUFS : 0; > > > > > } > > > > > > > > > > +static int > > > > > +rts_ring_mp_enqueue(struct rte_mempool *mp, void * const *obj_ta= ble, > > > > > + unsigned int n) > > > > > +{ > > > > > + return rte_ring_mp_rts_enqueue_bulk(mp->pool_data, > > > > > + obj_table, n, NULL) =3D=3D 0 ? -ENOBUFS : 0; > > > > > +} > > > > > + > > > > > +static int > > > > > +hts_ring_mp_enqueue(struct rte_mempool *mp, void * const *obj_ta= ble, > > > > > + unsigned int n) > > > > > +{ > > > > > + return rte_ring_mp_hts_enqueue_bulk(mp->pool_data, > > > > > + obj_table, n, NULL) =3D=3D 0 ? -ENOBUFS : 0; > > > > > +} > > > > > + > > > > > static int > > > > > common_ring_mc_dequeue(struct rte_mempool *mp, void **obj_table,= unsigned n) > > > > > { > > > > > @@ -39,17 +55,30 @@ common_ring_sc_dequeue(struct rte_mempool *mp= , void **obj_table, unsigned n) > > > > > obj_table, n, NULL) =3D=3D 0 ? -ENOBUFS : 0; > > > > > } > > > > > > > > > > +static int > > > > > +rts_ring_mc_dequeue(struct rte_mempool *mp, void **obj_table, un= signed int n) > > > > > +{ > > > > > + return rte_ring_mc_rts_dequeue_bulk(mp->pool_data, > > > > > + obj_table, n, NULL) =3D=3D 0 ? -ENOBUFS : 0; > > > > > +} > > > > > + > > > > > +static int > > > > > +hts_ring_mc_dequeue(struct rte_mempool *mp, void **obj_table, un= signed int n) > > > > > +{ > > > > > + return rte_ring_mc_hts_dequeue_bulk(mp->pool_data, > > > > > + obj_table, n, NULL) =3D=3D 0 ? -ENOBUFS : 0; > > > > > +} > > > > > + > > > > > static unsigned > > > > > common_ring_get_count(const struct rte_mempool *mp) > > > > > { > > > > > return rte_ring_count(mp->pool_data); > > > > > } > > > > > > > > > > - > > > > > static int > > > > > -common_ring_alloc(struct rte_mempool *mp) > > > > > +ring_alloc(struct rte_mempool *mp, uint32_t rg_flags) > > > > > { > > > > > - int rg_flags =3D 0, ret; > > > > > + int ret; > > > > > char rg_name[RTE_RING_NAMESIZE]; > > > > > struct rte_ring *r; > > > > > > > > > > @@ -60,12 +89,6 @@ common_ring_alloc(struct rte_mempool *mp) > > > > > return -rte_errno; > > > > > } > > > > > > > > > > - /* ring flags */ > > > > > - if (mp->flags & MEMPOOL_F_SP_PUT) > > > > > - rg_flags |=3D RING_F_SP_ENQ; > > > > > - if (mp->flags & MEMPOOL_F_SC_GET) > > > > > - rg_flags |=3D RING_F_SC_DEQ; > > > > > - > > > > > /* > > > > > * Allocate the ring that will be used to store objects. > > > > > * Ring functions will return appropriate errors if we are > > > > > @@ -82,6 +105,40 @@ common_ring_alloc(struct rte_mempool *mp) > > > > > return 0; > > > > > } > > > > > > > > > > +static int > > > > > +common_ring_alloc(struct rte_mempool *mp) > > > > > +{ > > > > > + uint32_t rg_flags; > > > > > + > > > > > + rg_flags =3D 0; > > > > > > > > Maybe it could go on the same line > > > > > > > > > + > > > > > + /* ring flags */ > > > > > > > > Not sure we need to keep this comment > > > > > > > > > + if (mp->flags & MEMPOOL_F_SP_PUT) > > > > > + rg_flags |=3D RING_F_SP_ENQ; > > > > > + if (mp->flags & MEMPOOL_F_SC_GET) > > > > > + rg_flags |=3D RING_F_SC_DEQ; > > > > > + > > > > > + return ring_alloc(mp, rg_flags); > > > > > +} > > > > > + > > > > > +static int > > > > > +rts_ring_alloc(struct rte_mempool *mp) > > > > > +{ > > > > > + if ((mp->flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET)) !=3D 0) > > > > > + return -EINVAL; > > > > > > > > Why do we need this? It is a problem to allow sc/sp in this mode (e= ven > > > > if it's not optimal)? > > > > > > These new sync modes (RTS, HTS) are for MT. > > > For SP/SC - there is simply no point to use MT sync modes. > > > I suppose there are few choices: > > > 1. Make F_SP_PUT/F_SC_GET flags silently override expected ops behavi= our > > > and create actual ring with ST sync mode for prod/cons. > > > 2. Report an error. > > > 3. Silently ignore these flags. > > > > > > As I can see for "ring_mp_mc" ops, we doing #1, > > > while for "stack" we are doing #3. > > > For RTS/HTS I chosoe #2, as it seems cleaner to me. > > > Any thoughts from your side what preferable behaviour should be? > > > > The F_SP_PUT/F_SC_GET are only used in rte_mempool_create() to select > > the default ops among (ring_sp_sc, ring_mp_sc, ring_sp_mc, > > ring_mp_mc). >=20 > As I understand, nothing prevents user from doing: >=20 > mp =3D rte_mempool_create_empty(name, n, elt_size, cache_size, > sizeof(struct rte_pktmbuf_pool_private), socket_id, 0); Apologies, hit send accidently. I meant user can do: mp =3D rte_mempool_create_empty(..., F_SP_PUT | F_SC_GET); rte_mempool_set_ops_byname(mp, "ring_mp_mc", NULL); An in that case, he'll get SP/SC ring underneath. >=20 >=20 > >I don't think we should look at it when using specific ops. > > > > So I'll tend to say 3. is the correct thing to do. >=20 > Ok, will resend v3 then. >=20