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 09AFDA04F3; Tue, 7 Jan 2020 16:41:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4B2391D9D8; Tue, 7 Jan 2020 16:41:32 +0100 (CET) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id C23F31D9D7 for ; Tue, 7 Jan 2020 16:41:30 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2020 07:41:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,406,1571727600"; d="scan'208";a="422536194" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga006.fm.intel.com with ESMTP; 07 Jan 2020 07:41:29 -0800 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 7 Jan 2020 07:41:29 -0800 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 7 Jan 2020 07:41:28 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.56) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 7 Jan 2020 07:41:28 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IoxiDoNR+pzC9AFoe9pGxsntjJh2RLwz5gjPdIbY6CHz20ROEEQckE1BcyCKw7tml8PTFbNUZawOBjxyOF6M+n69hTsnxRxrJ6NaHPo64+GfgYZfH/9d+1WXehwRpYbEaKV/8EC4PXXqv9w2XGZed5vHnBl+09vNoXCknRz5DE1g0+j2jERwVFA06LdBznH2aLJ/Cx84prN4h2OOD4rvT/9GKaWpA+8p73RUB1c1ImlK/GnmVOYDcO+Ie+n7lY7nMUiMlV4fFOmPfjT5Q7XEhz8x/3ltZ6QLUR+VS0UOVGrIu+/Qz2je6ICA3E/jk+yCVAYuWmazG7vX81D9tq378g== 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=+L3YKwawwXKVX4wnvD47y5PGkKaYpiG2fn2N+bxrBDs=; b=Rs4aKcavXjrbx22aUKdsjM/AKnhObQiPVhNEiYrIbpzayOSNr3U0AiBR9gtDVouzD/coNzizJsizqtNeTOijJyWQzmUx9ERVEexkB9Xe7ecgi8wB/2vl3e4pPzeVNKsfGYhXhd8aSMVjWJQ0Yb+UwOduduWprhs11iNLWH+YHUTnoiDPnfMCUg/20K2PGliLY+drERXRox2ZTtFbLeIMv6Pr3og4atApyu3hOcVd3E8KtXiB1TT0jaeM/I+kKMTg0FmbCwWK7QIAji4yCSoK7YLBzWfJgeezCi4yaN3J5ZlEft2BEPbtCOZH2gNHsr+DqnV7ruDKIVaRCcdIC+mynQ== 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=+L3YKwawwXKVX4wnvD47y5PGkKaYpiG2fn2N+bxrBDs=; b=k6uHdaHJYn9GUpj+rDs2nXDyAb32EOC/BNtBRVvquJTCKNY8OxNBMj/toWaXhnap2AWf1bva6S5tjYO/i+kqfZx9ijNMbr4CNyrgbIKzgzlMbNVFOL7rvmgdWEUv2iKLrP+bbHjopDDmiMPHcA5TFSJqGvcqJbNd72ra3lCHo6w= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (52.135.94.19) by SN6PR11MB3246.namprd11.prod.outlook.com (52.135.109.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Tue, 7 Jan 2020 15:41:27 +0000 Received: from SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::4d86:362a:13c3:8386]) by SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::4d86:362a:13c3:8386%7]) with mapi id 15.20.2623.008; Tue, 7 Jan 2020 15:41:27 +0000 From: "Ananyev, Konstantin" To: Honnappa Nagarahalli , "olivier.matz@6wind.com" , "sthemmin@microsoft.com" , "jerinj@marvell.com" , "Richardson, Bruce" , "david.marchand@redhat.com" , "pbhagavatula@marvell.com" CC: "dev@dpdk.org" , Dharmik Thakkar , Ruifeng Wang , Gavin Hu , nd , nd Thread-Topic: [PATCH v7 02/17] lib/ring: apis to support configurable element size Thread-Index: AQHVtvB22uIJex5+gEyRiFOc8yhYEqfXpo/wgAckGwCAAAcRgIAAR9qggABU2wCAAAOEAA== Date: Tue, 7 Jan 2020 15:41:27 +0000 Message-ID: References: <20190906190510.11146-1-honnappa.nagarahalli@arm.com> <20191220044524.32910-1-honnappa.nagarahalli@arm.com> <20191220044524.32910-3-honnappa.nagarahalli@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmU4ODI0NzItMTUwNy00YzE3LWJiNzgtMGE5ZjE4ZDdhMzBlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYnBLTTlaU3B2R3hGTGJ6cVUweko2c1VwVk9yaFhITEYwQ2kyQXoxWnB1SFR6Z1JDMWdaR0UxYmdENzc2dFZyZCJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.179] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9912ff48-d0d3-4dce-15a7-08d793880f17 x-ms-traffictypediagnostic: SN6PR11MB3246: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(39860400002)(346002)(396003)(199004)(189003)(7696005)(316002)(81156014)(66946007)(66446008)(6506007)(7416002)(478600001)(186003)(66476007)(71200400001)(2906002)(66556008)(64756008)(76116006)(81166006)(8936002)(8676002)(26005)(33656002)(86362001)(4326008)(5660300002)(110136005)(52536014)(55016002)(54906003)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB3246; H:SN6PR11MB2558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BuysTgebIkJ4glDtlxwihsI7Nq737V1Ka+OBXfJhRJwgU8Nc27/fQAREoEjXlg6cJ+9lzS6yKetYnSXkesrZMuWpNn7BQRHUtSniaDku211P/32TmfsWQK9vt8m3pKV4ZuwqriCeKfWjtg+Y8SCPz+N1pnkUu/Hq+906q/uka91iiTMms1K47B02vmcIRdkT6zxfan9M3ZQ7IJSXkt30flcAGM/K+HhcwdIAJXXNHLP3AMcQzsheVc+o9bhCWlLgC9aMCYjXEfX2bnH+RZ0OdSRw/qwurbkGpp2x0qDNmP1CqKrP/9tMzMkIPJCnjZltlahTrr1r/tNcrDsb/5JvrcQyd/x5qTsmtkAWGGR4AOzQD0o6CSD5fVo6aig43HA3sREhLl1xFN/SdIRGV+XbVcEgGzAX054Ck+tTxiNsndRPF8UDnl/WsbKnkasWYtWC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9912ff48-d0d3-4dce-15a7-08d793880f17 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 15:41:27.2591 (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: kdmAYFHyr6U3Cz/r3TewJPTzT3aIVKRfDnO+Ihv9FCN9bKD5sS+9a5GEG1wPpY1bvHsJgU1qAw10KDjrZLE3EbiATvrhYPT/LHRB8vtUg2A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3246 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v7 02/17] lib/ring: apis to support configurable element size 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" > > > > > > > + > > > > > > +static __rte_always_inline void enqueue_elems_128(struct > > > > > > +rte_ring *r, uint32_t prod_head, const void *obj_table, > > > > > > +uint32_t n) { unsigned int i; const uint32_t size =3D r->size; > > > > > > +uint32_t idx =3D prod_head & r->mask; __uint128_t *ring =3D > > > > > > +(__uint128_t *)&r[1]; const __uint128_t *obj =3D (const > > > > > > +__uint128_t *)obj_table; if (likely(idx + n < size)) { for (i = =3D > > > > > > +0; i < (n & ~0x1); i +=3D 2, idx +=3D 2) { ring[idx] =3D obj[i= ]; > > > > > > +ring[idx + 1] =3D obj[i + 1]; > > > > > > > > > > > > > > > AFAIK, that implies 16B aligned obj_table... > > > > > Would it always be the case? > > > > I am not sure from the compiler perspective. > > > > At least on Arm architecture, unaligned access (address that is > > > > accessed is not aligned to the size of the data element being > > > > accessed) will result in faults or require additional cycles. So, a= ligning on > > 16B should be fine. > > > Further, I would be changing this to use 'rte_int128_t' as '__uint128= _t' is > > not defined on 32b systems. > > > > What I am trying to say: with this code we imply new requirement for el= ems > The only existing use case in DPDK for 16B is the event ring. The event r= ing already does similar kind of copy (using 'struct rte_event'). > So, there is no change in expectations for event ring. > For future code, I think this expectation should be fine since it allows = for optimal code. >=20 > > in the ring: when sizeof(elem)=3D=3D16 it's alignment also has to be at= least 16. > > Which from my perspective is not ideal. > Any reasoning? New implicit requirement and inconsistency. Code like that: struct ring_elem {uint64_t a, b;}; .... struct ring_elem elem;=20 rte_ring_dequeue_elem(ring, &elem, sizeof(elem)); =20 might cause a crash. While exactly the same code with: struct ring_elem {uint64_t a, b, c;}; OR struct ring_elem {uint64_t a, b, c= , d;}; will work ok. >=20 > > Note that for elem sizes > 16 (24, 32), there is no such constraint. > The rest of them need to be aligned on 4B boundary. However, this should = not affect the existing code. > The code for 8B and 16B is kept as is to ensure the performance is not af= fected for the existing code. >=20 > > > > > > > > > > > > > > > > > > > > +} > > > > > > +switch (n & 0x1) { > > > > > > +case 1: > > > > > > +ring[idx++] =3D obj[i++]; > > > > > > +} > > > > > > +} else { > > > > > > +for (i =3D 0; idx < size; i++, idx++) ring[idx] =3D obj[i]; > > > > > > +/* Start at the beginning */ > > > > > > +for (idx =3D 0; i < n; i++, idx++) ring[idx] =3D obj[i]; } } > > > > > > + > > > > > > +/* the actual enqueue of elements on the ring. > > > > > > + * Placed here since identical code needed in both > > > > > > + * single and multi producer enqueue functions. > > > > > > + */ > > > > > > +static __rte_always_inline void enqueue_elems(struct rte_ring > > > > > > +*r, uint32_t prod_head, const void > > > > > *obj_table, > > > > > > +uint32_t esize, uint32_t num) > > > > > > +{ > > > > > > +uint32_t idx, nr_idx, nr_num; > > > > > > + > > > > > > +/* 8B and 16B copies implemented individually to retain > > > > > > + * the current performance. > > > > > > + */ > > > > > > +if (esize =3D=3D 8) > > > > > > +enqueue_elems_64(r, prod_head, obj_table, num); else if (esize > > > > > > +=3D=3D > > > > > > +16) enqueue_elems_128(r, prod_head, obj_table, num); else { > > > > > > +/* Normalize to uint32_t */ > > > > > > +uint32_t scale =3D esize / sizeof(uint32_t); nr_num =3D num * > > > > > > +scale; idx =3D prod_head & r->mask; nr_idx =3D idx * scale; > > > > > > +enqueue_elems_32(r, nr_idx, obj_table, nr_num); } } > > > > > > +