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 619F242AF7; Wed, 17 May 2023 15:20:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EC9DA40EE1; Wed, 17 May 2023 15:20:36 +0200 (CEST) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by mails.dpdk.org (Postfix) with ESMTP id 080BC406B7 for ; Wed, 17 May 2023 15:20:36 +0200 (CEST) Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4518d3a9b12so316214e0c.2 for ; Wed, 17 May 2023 06:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684329635; x=1686921635; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Bu/uATOEx8Tl9+eDLA5D/roeEr9io6Hqk9pIZjjGN3U=; b=BrAMJXAdfk7Ps6bPRNWKkX1j66u35HX0Q8UIOHWlEXSr1kRutp1sIREQCgUT4cSzwv 94gZ4R7NXq54bo3MYaHlMSzIglu+UMYsCzmwXau1HYMZyVEGAdKtM6wKxQPnBHAQ9XDI gQEfDMiNfd3WdukH+lze1YcRMiDLMjCXp14prs2qzi/coz7M3QS2FjWr1SOLLl675k2h SYdNwW4PEDSMJipLpjH7Lqf5wM3QZH+HcQHNZMavkQClQg3fIvYq+lmp7POidHK+D+xd y8X5D2wJftLnxmbc5yuS3obWdcaIqhQSmaAelQ1L/JoJyIgRpdM6N0l/b2dLhRG3pg/X IEvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684329635; x=1686921635; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Bu/uATOEx8Tl9+eDLA5D/roeEr9io6Hqk9pIZjjGN3U=; b=XIp7yrJro1Do/xvXz+bigfJnJgZGteIM9AvnRDhln4TG0i02Wkx0fTHNYhsX7cnb9T cBMY+FiC1I83SzHY4xGfz8TMu11sSOiORbPeiL7hETZTOlwg8myQws1Unc/pYkY21W/C cDr1V07FHxUR9JmV/fixyxtuNlaXhrrkQ+vCFiNZSnCTIvUuwjWKFaJ+YVlM98k/gCaP OOSJtJO7ehuVwu8OTncuivSb9TaswHSDEoIQy4x+MI497WUoZprvAvb/Ifgw7pQHkwyk BSimiMl5sOOmW5esqtfjMS0oejsXAkt+SuWlXh71yoJ9fIHgp3ZJhLMZgudDgtf6tuv4 48IQ== X-Gm-Message-State: AC+VfDxJ1HwehHXCErt/CItyD+ZnKgn0tN38Uo4M0wHQK5sbLBHRlk1S yL8Rafir6pFnyfQHk9JRqi+Fn9k/LYOWSwVJWso= X-Google-Smtp-Source: ACHHUZ6j13ZvuF2VNOTxVZWukRD7PIbJstGShlFSI0EzqZXVgCvw0dEoKyDGH7djyRAcOa1Kfe5biDLzgO3nIj6nDrc= X-Received: by 2002:a1f:60d8:0:b0:43f:b31b:f1d1 with SMTP id u207-20020a1f60d8000000b0043fb31bf1d1mr14297298vkb.13.1684329635258; Wed, 17 May 2023 06:20:35 -0700 (PDT) MIME-Version: 1.0 References: <20230418104547.547084-1-sivaprasad.tummala@amd.com> <8f006152-7cb7-6fc8-22e6-5187d7611430@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35D87890@smartserver.smartshare.dk> <5e726b4e-66eb-0b0c-59cb-04b9bf97fdb2@ericsson.com> In-Reply-To: <5e726b4e-66eb-0b0c-59cb-04b9bf97fdb2@ericsson.com> From: Jerin Jacob Date: Wed, 17 May 2023 18:50:08 +0530 Message-ID: Subject: Re: [PATCH] eventdev: fix alignment padding To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= , Sivaprasad Tummala , "jerinj@marvell.com" , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tue, Apr 18, 2023 at 8:46=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > > On 2023-04-18 16:07, Morten Br=C3=B8rup wrote: > >> From: Mattias R=C3=B6nnblom [mailto:mattias.ronnblom@ericsson.com] > >> Sent: Tuesday, 18 April 2023 14.31 > >> > >> On 2023-04-18 12:45, Sivaprasad Tummala wrote: > >>> fixed the padding required to align to cacheline size. > >>> > >> > >> What's the point in having this structure cache-line aligned? False > >> sharing is a non-issue, since this is more or less a read only struct. > >> > >> This is not so much a comment on your patch, but the __rte_cache_align= ed > >> attribute. > > > > When the structure is cache aligned, an individual entry in the array d= oes not unnecessarily cross a cache line border. With 16 pointers and align= ed, it uses exactly two cache lines. If unaligned, it may span three cache = lines. > > > An *element* in the reserved uint64_t array won't span across two cache > lines, regardless if __rte_cache_aligned is specified or not. You would > need a packed struct for that to occur, plus the reserved array field > being preceded by some appropriately-sized fields. > > The only effect __rte_cache_aligned has on this particular struct is > that if you instantiate the struct on the stack, or as a static > variable, it will be cache-line aligned. That effect you can get by > specifying the attribute when you define the variable, and you will save > some space (by having smaller elements). In this case it doesn't matter > if the array is compact or not, since an application is likely to only > use one of the members in the array. > > It also doesn't matter of the struct is two or three cache lines, as > long as only the first two are used. Discussions stalled at this point. Hi Shiva, Marking this patch as rejected. If you think the other way, Please change patchwork status and let's discuss more here. > > >> > >>> Fixes: 54f17843a887 ("eventdev: add port maintenance API") > >>> Cc: mattias.ronnblom@ericsson.com > >>> > >>> Signed-off-by: Sivaprasad Tummala > >>> --- > >>> lib/eventdev/rte_eventdev_core.h | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/lib/eventdev/rte_eventdev_core.h > >> b/lib/eventdev/rte_eventdev_core.h > >>> index c328bdbc82..c27a52ccc0 100644 > >>> --- a/lib/eventdev/rte_eventdev_core.h > >>> +++ b/lib/eventdev/rte_eventdev_core.h > >>> @@ -65,7 +65,7 @@ struct rte_event_fp_ops { > >>> /**< PMD Tx adapter enqueue same destination function. */ > >>> event_crypto_adapter_enqueue_t ca_enqueue; > >>> /**< PMD Crypto adapter enqueue function. */ > >>> - uintptr_t reserved[6]; > >>> + uintptr_t reserved[5]; > >>> } __rte_cache_aligned; > >>> > >>> extern struct rte_event_fp_ops rte_event_fp_ops[RTE_EVENT_MAX_DEVS= ]; > > >