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 C76C2A04FA; Wed, 8 Jan 2020 11:05:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 75F781D949; Wed, 8 Jan 2020 11:05:42 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 901EF1D913 for ; Wed, 8 Jan 2020 11:05:40 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 02:05:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,409,1571727600"; d="scan'208";a="254173376" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga002.fm.intel.com with ESMTP; 08 Jan 2020 02:05:39 -0800 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 02:05:39 -0800 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx101.amr.corp.intel.com (10.18.124.199) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 02:05:39 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.57) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 02:05:38 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z2KynJwb9CtcFfGCQLl+hcfSstNQPOLn/fwwBsxZVaHIGu564YCTGArjGRjSkxZ7/vHxBcot/Sf3wlNSdM1+5bKi5IrUIBpfog4bhi1t8oSkVf6G/naUPyLdVicUpXA5aKRDcZgQWBHb4tZfXq+vLp82LqNtKXJC56d2Do41XYIWk536UTWqPYBMxoIaYuDt/an8WYdqWD6MaotftWxLo7MnKj2fmaVF+ebqyFDn71jZ0Zurtp6DMjDkNajp3atq2apetLNqj8TiAF43XSK2cNzsT9Zxx4bxh+3VugYoBe+AOXAe2URU4TFTBwhn8Q+JeqcGbWnVpQGQjq1cbk9UrA== 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=MFBxmI5HDBCfOOhCxQSmmSGCD/aj2j3jsGN2lkNj2H4=; b=L3qG77XwQvz7vtWjZwnL7HLCVECULJ1BmXUlKgWQuuhh40uhJenpa0OPPe6g24MyL1d+vuN2nU6UwDarCwpGYWlbfy4hfjcDgR+DY7oJJk/P6RjHbmlvCbx3YFT088OY/SHNqdkfQOPlCX8Mo4l0Unixxtraimqr9g7Qpk/nlhjjb2TV6dGL56Y6qxEIbeL9zB0ZSbS3EeueWTlSfHw8ex9qkj9I/GkFSm/xcMhqJtjOLPO1e8A9n3a7YoZ/M88fMg2PCegmmpNO+0SCwhd+oSj0GpKX9i/FPS0h127lQrOjHvL0R1mkrz1rI6xL0lbjD45pQqiu7w0/+/YPnfLSDg== 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=MFBxmI5HDBCfOOhCxQSmmSGCD/aj2j3jsGN2lkNj2H4=; b=y0SD5ER0iPSG2DFTKG9f47T44KxTztP40n9LTe5RWL74t4/Ty3KaJ4aG5C/ZNceQ40scmQ7RlV/s8mCDP0ZhEES9Io101Se7NTwws8zpvbUDG4fXxeGPEcL/uxF9dherYxu29uXIym9q4SsMWiKnGgB96strKoNOsnV5ir1PbyU= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (52.135.94.19) by SN6PR11MB2605.namprd11.prod.outlook.com (52.135.97.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Wed, 8 Jan 2020 10:05:23 +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; Wed, 8 Jan 2020 10:05:23 +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/wgAckGwCAAAcRgIAAR9qggABU2wCAAAOEAIAA9tKAgAA+MMA= Date: Wed, 8 Jan 2020 10:05:23 +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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDRlYmY5NGQtMGIzZi00NGFlLTk1M2ItMmZhM2VkYjk0Zjc3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQXNIbndsS011Q1ZNUTFPYWNFSEttOGxNSThBSGpESjUzWjZIV3BIbGNWQmZ3NXhSbVN0OGVUYlwvXC9pRThyTzlzIn0= 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.163] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46da6544-b849-4659-46c2-08d7942246db x-ms-traffictypediagnostic: SN6PR11MB2605: 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:10000; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(396003)(376002)(136003)(199004)(189003)(8936002)(186003)(55016002)(52536014)(2906002)(110136005)(7416002)(86362001)(5660300002)(478600001)(4326008)(316002)(54906003)(9686003)(66446008)(6506007)(66476007)(66556008)(64756008)(66946007)(76116006)(8676002)(33656002)(81166006)(81156014)(7696005)(26005)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB2605; 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: CONkWOij96OTFHa8TeTuR061AujxKKy1qdg8QMnsWlEIlnUoaeWZk4AUvCvqVG+iy8DsvXSZ1RMITsiJRAqVNOiQO7rV7Su8svjhk3kGrg1PRUukTS7yXWGsZxZ6oMGoWAJBvdMfg7C1kfvjvULnh9qK5J3KRN5MxuPalX5R+lEbV2fsRRAbgJQc1itfHWxKQjvfDjKAocMoAwdZfIxe/SnE8ETPGrlUk/GgLThgXYy4y5ztfFd6w8idB/ERS/ONL+fEAXo5XzeJzcEpgO4j7M7JcBf9v+L34ywo71CBzbGPyQ0e1/dUVhafFmwX36tEnnuu8oMpS+N+of2lCE5aQ6n0lgxBtSutGJKbBFc0ize7jGIZHqqdp4ZdfDcyDQy9MYMmOrJqaMd1r6+wb0XvbCQwgJdv/bEyOB2DQpkYTaj2OXrJID74CGGrLLxjkg2x Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 46da6544-b849-4659-46c2-08d7942246db X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 10:05:23.3319 (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: ptBA8w+ncARlCL8xIiR/jC3nMx0DBOywHOecBFsOB4di7mK71zhKpGyVIZphI0iuc6/+AU9Bz5Sx7Aw2Jyd6Xx3c2ZJfn2ASst9e5UlXk0M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2605 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) { ri= ng[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, aligning 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 fo= r > > > > elems > > > The only existing use case in DPDK for 16B is the event ring. The eve= nt ring > > 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 all= ows for > > optimal code. > > > > > > > in the ring: when sizeof(elem)=3D=3D16 it's alignment also has to b= e 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; > > rte_ring_dequeue_elem(ring, &elem, sizeof(elem)); > > > > might cause a crash. > The alignment here is 8B. Assuming that instructions generated will requi= re 16B alignment, it will result in a crash, if configured to generate > exception. > But, these instructions are not atomic instructions. At least on aarch64,= unaligned access will not result in an exception for non-atomic > loads/stores. I believe it is the same behavior for x86 as well. On IA, there are 2 types of 16B load/store instructions: aligned and unalig= ned. Aligned are a bit faster, but will cause an exception if used on non 16B al= igned address.=20 As you using uint128_t * compiler will assume that both src and dst are 16B= aligned and might generate code with aligned instructions. >=20 > > 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. > The alignment for these structures is still 8B. Are you saying this will = work because these will be copied using pointer to uint32_t (whose > alignment is 4B)? Yes, as we doing uint32_t copies, compiler can't assume the data will be 16= B aligned and will use unaligned instructions. >=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 sho= uld > > not affect the existing code. > > > The code for 8B and 16B is kept as is to ensure the performance is no= t > > affected for the existing code. >