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 B2F3DA0542; Tue, 5 Jul 2022 10:54:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A2BED4021D; Tue, 5 Jul 2022 10:54:59 +0200 (CEST) Received: from forward500o.mail.yandex.net (forward500o.mail.yandex.net [37.140.190.195]) by mails.dpdk.org (Postfix) with ESMTP id ADC0D400D7 for ; Tue, 5 Jul 2022 10:54:58 +0200 (CEST) Received: from myt5-00a806c30094.qloud-c.yandex.net (myt5-00a806c30094.qloud-c.yandex.net [IPv6:2a02:6b8:c12:f92:0:640:a8:6c3]) by forward500o.mail.yandex.net (Yandex) with ESMTP id 03BF6942790; Tue, 5 Jul 2022 11:54:58 +0300 (MSK) Received: from myt5-aad1beefab42.qloud-c.yandex.net (myt5-aad1beefab42.qloud-c.yandex.net [2a02:6b8:c12:128:0:640:aad1:beef]) by myt5-00a806c30094.qloud-c.yandex.net (mxback/Yandex) with ESMTP id Eap8iM9yJh-svfS27Z4; Tue, 05 Jul 2022 11:54:57 +0300 X-Yandex-Fwd: 2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1657011297; bh=KZrMuCNviJ/G5y9+E7yNDmOztiOMPJTV55Z/DWJIGh0=; h=In-Reply-To:From:Subject:References:Date:Message-ID:To; b=AfkXTQaTEQInOSerz/T9WYtob1Ea1+jz1/RY1+POTYkpwsQM9i9GwcHq1jYs4m8Do 7gB1erL2p45DbIe7gmzjb5r2poeribiCthQLtrpq8n37ePb/sFpb9oBNTFyauuJ7hV o8riGUsSCkx6b4ljVD9FEXYrgQAQMPPuuBIHWaqQ= Authentication-Results: myt5-00a806c30094.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt5-aad1beefab42.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id m7IhQYKvg2-sve0pSMa; Tue, 05 Jul 2022 11:54:57 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: <3fefdb57-1b62-71d7-48f1-6d2332dd423f@yandex.ru> Date: Tue, 5 Jul 2022 09:54:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: rte_ring_elem_pvt historical question Content-Language: en-US To: =?UTF-8?Q?Morten_Br=c3=b8rup?= , dev@dpdk.org References: <98CBD80474FA8B44BF855DF32C47DC35D871A5@smartserver.smartshare.dk> From: Konstantin Ananyev In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D871A5@smartserver.smartshare.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 04/07/2022 12:35, Morten Brørup пишет: > Does anyone here remember why the __rte_ring_enqueue/dequeue_elems_64/128() functions support unaligned object arrays, when the __rte_ring_enqueue/dequeue_elems_32() functions require 4 byte aligned object arrays? As I remember, we added 'unaligned' to be able to use rte_ring with elements that might have smaller alignment. For 32 - as I remember we never explicitly require 4B aligned objects for the rings ... Am I missing something here? My guess, we just never hit such problem so it gets unnoticed. Probably worth updating 32-bit version too with explicit 'unaligned' type. > > I'm wondering if the compiler could do better with a simpler implementation than the manually implemented loop unrolls, and if the unalignment silliness would stand in the way. > > Med venlig hilsen / Kind regards, > -Morten Brørup >