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 D1C0943315; Mon, 13 Nov 2023 07:40:13 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 95FCC402E0; Mon, 13 Nov 2023 07:40:13 +0100 (CET) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2074.outbound.protection.outlook.com [40.107.22.74]) by mails.dpdk.org (Postfix) with ESMTP id 9F391402BD for ; Mon, 13 Nov 2023 07:40:11 +0100 (CET) ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=P93ulcTgoh1MjBzgxvp4NwWyAXEbHOEpad+lZvV1/kX4jBotobDW3JBD+8Tls5A65byZ8Ky8KTv4H9ri7174Yjcyc0HlhVavtxQb7q0t+90nvXpT2vPtwggT0QllF64MtoAzirPQL+q8eizF19PpdMdducxXNyctR5ADG/goTzBVVp7nKh2mdoSIWGblL4R/t14S12hrETMdnMOguAOyQWgacs37p1NDGXAZnMblnAX9QYZ+1T0rQ0Vb7vE0nzqaDIiC6yY81iTIPtgZ/gqrsccu5i1r28QhKCjdHIrWJoMHrnyzxGPIkqpgmFhtTrSUgbpcFMgF6frK6hZ75rg0BA== ARC-Message-Signature: i=2; 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=fJeNb5DKtROJpQKcCESBlW4WaaoxSnUECoiW2bma83E=; b=f29Sxsb3rx5gAAbwIGmybkr56RFp0DgQHa/bpKanZolZSE7g181tGSS4Eot3XsOQPNta+H3ElX6NOTYNV1PbeQTq2SBPwrwwEMXolrvIsAsF2mspWfjhj3CIiJx8P6v/FiqFis4WmxPCuqj7CgFyjKDAMt3PfuuUFLEawJ9VL4gjOQ5B88SytBCo1SxPAHvxr1veUUcrvUMAxouAYtzxj8rR4UMP52ljUUNJeJY9c+09YEH49HjZSy/t0CVN9o25HezwcYZYyOIT5Rkqj/5Amd5zhvPNy3iEt2mHcu7dhuIgmgmOuf4yj+Xvv4MLSCZ4rr1TZpJKcXOLMHZMnevVEQ== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=dpdk.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fJeNb5DKtROJpQKcCESBlW4WaaoxSnUECoiW2bma83E=; b=kduC/FEJCtJxYTQJxDhmjuePIsKOzvB9oNmMf5AOaLJiOxCI5hQmVRS//TA+1VRckp38Mx042DeT9+mHTb2SajHGs3XSYlXWynnMBPBLvbvDDy7bt9eSoz/JYGeCNrIIDChQxkQzaWcLwousUHOXCwoRD5OoL4U7yTEMcYHXKN8= Received: from AM6PR10CA0073.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::14) by DB9PR08MB8724.eurprd08.prod.outlook.com (2603:10a6:10:3d0::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.28; Mon, 13 Nov 2023 06:40:08 +0000 Received: from AMS0EPF000001A4.eurprd05.prod.outlook.com (2603:10a6:209:8c:cafe::a) by AM6PR10CA0073.outlook.office365.com (2603:10a6:209:8c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.29 via Frontend Transport; Mon, 13 Nov 2023 06:40:08 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AMS0EPF000001A4.mail.protection.outlook.com (10.167.16.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.13 via Frontend Transport; Mon, 13 Nov 2023 06:40:07 +0000 Received: ("Tessian outbound 8289ea11ec17:v228"); Mon, 13 Nov 2023 06:40:07 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: eac0f341e7494095 X-CR-MTA-TID: 64aa7808 Received: from 8056df7eaab3.3 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6A0C698B-7E53-4DBD-A478-B9D1570886E4.1; Mon, 13 Nov 2023 06:39:56 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 8056df7eaab3.3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 13 Nov 2023 06:39:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y0mEHZ76TBLVkGjInmOn1TfhDkPSA8aJ3puyd3UofPBLhMpzatuBNfwonxYnIy3dtJmxy/P8THnx+/pdVxLxZfjGkj3w1PI6113fheIAO9SCATQmwwlgFZOSC5pCELrYNhE95s3zlgxAdPGqe7bBGn+C7/G7mFX+GnlOIH1Y22I74U0fhC0KvUZXjHGg7A/VnM874CycL62mhvxJpFP9RzN54ENJoY38yMqZeTQ3BL0Ntv+XAz5Njb7tqnBscr6G0/0dzdIS6OP2PA20Y/kf865wWZ5CEpVBwxLaogPbqpB/ROwAajYDw1bNzcjTJq6JWooEpUI7Mg4Yka+xbrbOcg== 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=fJeNb5DKtROJpQKcCESBlW4WaaoxSnUECoiW2bma83E=; b=my9osZMCrXH39WsguVZkXVS/oVJh4d2Yhzumtkuy4jUC8C8n41iGW6wh/TD0ompiHaTv/dbbAj1p6P/UmwneSo3WWX99wgixyN2nlyfUPNTHHjHzUiiggjs1k3q8RkKEIGTTzjEwQzZXjuU3yIXHSfhHfJ/NtDDZtJPubvul4vBlH8r6nXoXdswse4NYKVJDmjzv9zeMQqcH1GkPNs4kNR5fIrXnGatIgE4RpmHHspYlzEG8y4aDZMiYRNvbPdJ720EYZM2MqunaE1vhf/oJSlFB0m45KGsElr/b89KEvQRA7iLMx/sOfNG+CN2IkKRKTQbc41Fx9n/b133Bi1Wltg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fJeNb5DKtROJpQKcCESBlW4WaaoxSnUECoiW2bma83E=; b=kduC/FEJCtJxYTQJxDhmjuePIsKOzvB9oNmMf5AOaLJiOxCI5hQmVRS//TA+1VRckp38Mx042DeT9+mHTb2SajHGs3XSYlXWynnMBPBLvbvDDy7bt9eSoz/JYGeCNrIIDChQxkQzaWcLwousUHOXCwoRD5OoL4U7yTEMcYHXKN8= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from AS8PR08MB7080.eurprd08.prod.outlook.com (2603:10a6:20b:401::19) by PAVPR08MB10337.eurprd08.prod.outlook.com (2603:10a6:102:30e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.29; Mon, 13 Nov 2023 06:39:53 +0000 Received: from AS8PR08MB7080.eurprd08.prod.outlook.com ([fe80::71ce:adb:6583:a151]) by AS8PR08MB7080.eurprd08.prod.outlook.com ([fe80::71ce:adb:6583:a151%6]) with mapi id 15.20.6977.029; Mon, 13 Nov 2023 06:39:53 +0000 Message-ID: Date: Mon, 13 Nov 2023 14:39:44 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [dpdk-dev] [PATCH] ring: fix unaligned memory access on aarch32 Content-Language: en-US To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: dev@dpdk.org, david.marchand@redhat.com, olivier.matz@6wind.com, dharmik.thakkar@arm.com, nd@arm.com, andrew.rybchenko@oktetlabs.ru, Gavin Hu , Konstantin Ananyev , honnappa.nagarahalli@arm.com, Min Zhou , David Christensen , Stanislaw Kardach , Bruce Richardson , konstantin.v.ananyev@yandex.ru References: <1583774395-10233-1-git-send-email-phil.yang@arm.com> <98CBD80474FA8B44BF855DF32C47DC35E9EFD1@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F00F@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F010@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F012@smartserver.smartshare.dk> From: Ruifeng Wang In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F012@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI1PR02CA0055.apcprd02.prod.outlook.com (2603:1096:4:1f5::16) To AS8PR08MB7080.eurprd08.prod.outlook.com (2603:10a6:20b:401::19) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: AS8PR08MB7080:EE_|PAVPR08MB10337:EE_|AMS0EPF000001A4:EE_|DB9PR08MB8724:EE_ X-MS-Office365-Filtering-Correlation-Id: 9d2eb322-09e9-4898-8996-08dbe413608b x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: YcePOqDZKv60qb0zp23h3xC8ICc5xrsvGMA8vgIhQHoKRaJCNRnVURwajntf+xoy1zQa+4IhBBF5kDSNUX8m8UOdzD5YHWjvOWj2Tx/nEoFnRgZZRhl9pF2zh7ByrmyM+dtwU4CfXfF2iPghT+T2xtiUhR/RlrffPhi6qkmL/FtOsQkmJwanUwK5AQZO8ga5a8nqbpMYAz8XfIE04sb7Ssu2OI8u7ADpBy9pot+P9hQxtTPreeBJB19CBUDKKUToPjMOIriuU2oEhlCNotcV9uuPJ7+YKMUz5VpRJMGO5iVmKFgHP9GhRc6TZIsHDOBWGURu2hbSC3BrRdrTeiPceAL0lMPyT4oCK3dMPr1IXRwsWRTrNyQobxx9cURCkGwUENy59L3ZuqxJoiCNbDiE29uoDnyyzI6lEtLfUUryYbkWgtsGk1878/JZv9ynir10TvDcF25hkdKOuFukQ+elud2NSeStZbiUGZ/9sAR5LfDbRd7I2RCD4O25crdSEVQ2kQ43NlcOzZLpACzkA4R9PCp4Ufa6oqCA51otlTv+rOJHLjXulxZ0aJvchau7XbRUz32n+fhi4UNgeeSEM0/U7G+TIbtzPeRhv9lbYBvTgQaociiqY1m8/Gg3dpBpNo0JWEErB/a935HBqWacYV8+yH1rPW+P+QlX8TqEBCjH4G4= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR08MB7080.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(376002)(346002)(39860400002)(136003)(396003)(230922051799003)(451199024)(186009)(1800799009)(64100799003)(7416002)(2906002)(2616005)(5660300002)(86362001)(31696002)(41300700001)(66574015)(26005)(54906003)(66556008)(66946007)(66476007)(6916009)(6512007)(316002)(83380400001)(38100700002)(966005)(31686004)(6666004)(478600001)(6486002)(36756003)(53546011)(6506007)(8676002)(4326008)(8936002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB10337 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AMS0EPF000001A4.eurprd05.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 5a6a48e1-6987-4c0b-d20b-08dbe4135784 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Z0eCssHA604lud1hRuGFhKauU9DEqv8XVe+978+5P9xrgHPGYgfXe9vCFqr0C/rvL/L7teHpwRrKq09LHGc7oMukXcuSfPdVK+UrQrBBu0QqyKAb46HuYGgMJPtUjh+7H/x251NZ5SN2uX/bG1UDNGqEiITe+LsE2z77aBy9u1aLCPcBxI3jvOVhAtX0ewLREkdyHlB1a3dRb2AoOCNoeVeoU5itv0ErBCc//UUR07cHjBlhYCj+ntRGqjfICvkE5pE7qGMW3RQas5eHJe4Cl3xR55i5WLOFUIijGQ40GHT7KMvrtUx8IpdJLeGrerccDXamE4wddgcGMHBwswLr4B0WzViRs/tay5/CE/mEgvdOPRGAp9GIzl5xwFt0/fr3ICpJQrTfHUPSnvPxvL8kxz0YfmiAhnHq9Zy3MWcVE1TxQyd8u9QEZmHMBlrLZOSzT4O10983YVmU20j/MkXp2ONLMcBrhfGIO5zdVzAea+ARF8Kq9PPeNddau/hmKvAgECLX37/dPU192XE2NLMl6a7SMWADeJqbNYxDeo9E2pRTX6e7qV9z0Aw0i/n1CBBL+LTvIwm6JLZ0gpHtcwcrjJMK5xbSuqNzJUaUXC/jFLHaGh+8tjF2IJ080d03p6U5BLSFjIUiAkN2DDPwTU1uRTjFqIWPcSrE1oMGMDwMak6A1EF1cICv4NZp6fLzlNPpZXLiPPQUag6tUQVKHTVNgdHrjB2BxySmufS/mfQoKxmrGim3B9nRU8AKb7JnpQSuvC7JvRm87JFNn+bvn+pgdytgi2O1kRzxkiuDnvMECcM= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230031)(4636009)(39860400002)(136003)(396003)(346002)(376002)(230922051799003)(451199024)(186009)(1800799009)(64100799003)(82310400011)(36840700001)(40470700004)(46966006)(107886003)(36860700001)(2906002)(40460700003)(2616005)(5660300002)(86362001)(31696002)(41300700001)(47076005)(66574015)(336012)(26005)(82740400003)(54906003)(70586007)(70206006)(6512007)(316002)(83380400001)(966005)(31686004)(478600001)(81166007)(6486002)(36756003)(53546011)(356005)(6506007)(6666004)(8676002)(6862004)(4326008)(40480700001)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2023 06:40:07.7544 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9d2eb322-09e9-4898-8996-08dbe413608b X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AMS0EPF000001A4.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB8724 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 On 2023/11/10 9:18 PM, Morten Brørup wrote: > Dear Ruifeng, Hi Morten, > +CC: all CPU architecture maintainers, > > I'm trying to figure out the requirements for supporting unaligned memory access in DPDK (specifically the ring library), and need your expert feedback. > > The #define RTE_ARCH_STRICT_ALIGN - which is undocumented, but probably means that CPU memory access must be aligned - is only set by "generic_aarch32". > > So we will assume that all other CPU architectures supported by DPDK can access unaligned memory. > > As discussed in this thread, "generic_aarch32" has special requirements for performing 64-bit load/store at unaligned addresses. Yes, 64-bit load/store at unaligned addresses causes alignment fault. > > Now comes the big question: Can "generic_aarch32" perform 32-bit load/store at unaligned addresses without similar special requirements? Then the ring library already supports unaligned 32-bit objects, and doesn't need to be fixed in this regard. Yes, 32-bit load/store support unaligned data accesses to normal memory (not device memory). This is documented in Arm Architecture Reference Manual. Thanks, Ruifeng > > > Med venlig hilsen / Kind regards, > -Morten Brørup > > >> From: Morten Brørup [mailto:mb@smartsharesystems.com] >> Sent: Friday, 10 November 2023 11.44 >> >>> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com] >>> Sent: Friday, 10 November 2023 10.45 >>> >>>> From: Morten Brørup >>>> Sent: Friday, November 10, 2023 9:34 AM >>>> >>>> +CC Gavin, reviewed the test case >>>> >>>>> From: Ruifeng Wang [mailto:Ruifeng.Wang@arm.com] >>>>> Sent: Friday, 10 November 2023 09.40 >>>>> >>>>> On 2023/11/4 8:04 AM, Morten Brørup wrote: >>>>>> I have for a long time now wondered why the ring functions for >>>>> enqueue/dequeue of 64-bit objects supports unaligned addresses, >> and >>> now >>>>> I finally found the patch introducing it. >>>>>> >>>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Phil Yang >>>>>>> Sent: Monday, 9 March 2020 18.20 >>>>>>> >>>>>>> The 32-bit arm machine doesn't support unaligned memory >> access. >>> It >>>>>>> will cause a bus error on aarch32 with the custom element size >>> ring. >>>>>>> >>>>>>> Thread 1 "test" received signal SIGBUS, Bus error. >>>>>>> __rte_ring_enqueue_elems_64 (n=1, obj_table=0xf5edfe41, >>> prod_head=0, >>>>> \ >>>>>>> r=0xf5edfb80) at /build/dpdk/build/include/rte_ring_elem.h:177 >>>>>>> 177 ring[idx++] = obj[i++]; >>>>>> >>>>>> Which test is this? Why is it using an unaligned array of 64- >> bit >>>>> objects? (Notice that obj_table=0xf5edfe41.) >>>>> >>>>> The test case is: >>>>> >>> >> https://elixir.bootlin.com/dpdk/latest/source/app/test/test_ring.c#L112 >>>>> 1 >>>>> This case deliberately use unaligned objects. >>>> >>>> Thank you, Ruifeng. >>>> >>>> Honnappa, I see you signed off on the patch introducing the test >> for >>> unaligned objects: >>>> >>> >> http://git.dpdk.org/dpdk/commit/app/test/test_ring.c?id=a9fe152363e283d >>> 4c590ab8e8d51396f2ffab9ff >>>> >>>> What was the rationale behind testing support for unaligned object >>> pointers? Did any applications/customers use unaligned object >>>> pointers, or is it a purely academic test case? >>>> >>>>> >>>>>> >>>>>> Nobody in their right mind would use an unaligned array of 64- >> bit >>>>> objects. You can only create such an array if you force the >>> compiler to >>>>> prevent automatic alignment! And all the functions in your >>> application >>>>> using this array would also need to support unaligned addressing >> of >>>>> these objects. >>> >>> It could be just one elem, not an array. >>> And the user can use 'packed' struct or so... >>> Agree, not a common case, but probably still possible. >> >> Very good point, Konstantin. A single unaligned object in a packed >> structure is not as exotic as an unaligned array of objects (which I >> consider completely unrealistic). >> >> If anyone is using an architecture which doesn't support unaligned >> accesses, I would expect them to completely avoid using unaligned >> objects. But perhaps you are right; however unlikely, it might happen. >> >> If we think this is a real use case, should we add support for >> unaligned 32 bit objects? >> (128 bit objects already support unaligned access; they are type casted >> to void pointer and accessed using memcpy().) >> >> And how about the stack library, should it support unaligned objects >> too? >> >>> >>>>>> >>>>>> This seems extremely exotic, and not something any real >>> application >>>>> would do! >>>>>> >>>>>> I would like to revert this patch for performance reasons. >>> >>> Morten, could you probably explain first the problems you encountered >>> with this patch? >>> You mention about 'performance reasons', so did you notice any real >>> slowdown? >> >> Please check my reply to the same question here: >> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35E9EFD3@smarts >> erver.smartshare.dk/ >> >>> >>>> >>>> I could add an RTE_ASSERT() to verify that the pointer is aligned, >>> for debugging purposes. >>>> >>>>>> >>>>>>> >>>>>>> Fixes: cc4b218790f6 ("ring: support configurable element >> size") >>>>>>> >>>>>>> Signed-off-by: Phil Yang >>>>>>> Reviewed-by: Ruifeng Wang >>>>>>> Reviewed-by: Honnappa Nagarahalli >> >>>>>>> --- >>>>>>> lib/librte_ring/rte_ring_elem.h | 4 ++-- >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> diff --git a/lib/librte_ring/rte_ring_elem.h >>>>>>> b/lib/librte_ring/rte_ring_elem.h >>>>>>> index 3976757..663addc 100644 >>>>>>> --- a/lib/librte_ring/rte_ring_elem.h >>>>>>> +++ b/lib/librte_ring/rte_ring_elem.h >>>>>>> @@ -160,7 +160,7 @@ __rte_ring_enqueue_elems_64(struct >> rte_ring >>> *r, >>>>>>> uint32_t prod_head, >>>>>>> const uint32_t size = r->size; >>>>>>> uint32_t idx = prod_head & r->mask; >>>>>>> uint64_t *ring = (uint64_t *)&r[1]; >>>>>>> - const uint64_t *obj = (const uint64_t *)obj_table; >>>>>>> + const unaligned_uint64_t *obj = (const unaligned_uint64_t >>>>>>> *)obj_table; >>>>>>> if (likely(idx + n < size)) { >>>>>>> for (i = 0; i < (n & ~0x3); i += 4, idx += 4) { >>>>>>> ring[idx] = obj[i]; >>>>>>> @@ -294,7 +294,7 @@ __rte_ring_dequeue_elems_64(struct >> rte_ring >>> *r, >>>>>>> uint32_t prod_head, >>>>>>> const uint32_t size = r->size; >>>>>>> uint32_t idx = prod_head & r->mask; >>>>>>> uint64_t *ring = (uint64_t *)&r[1]; >>>>>>> - uint64_t *obj = (uint64_t *)obj_table; >>>>>>> + unaligned_uint64_t *obj = (unaligned_uint64_t *)obj_table; >>>>>>> if (likely(idx + n < size)) { >>>>>>> for (i = 0; i < (n & ~0x3); i += 4, idx += 4) { >>>>>>> obj[i] = ring[idx]; >>>>>>> -- >>>>>>> 2.7.4 >>>>>>> >>>>>> >>>>>> References: >>>>>> >>>>> >>> >> https://git.dpdk.org/dpdk/commit/lib/librte_ring/rte_ring_elem.h?id=3ba >>>>> 51478a3ab3132c33effc8b132641233275b36 >>>>>> https://patchwork.dpdk.org/project/dpdk/patch/1583774395-10233- >> 1- >>> git- >>>>> send-email-phil.yang@arm.com/ >>>>>>