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 E1C1F43D14 for ; Thu, 21 Mar 2024 11:06:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D7B2842D80; Thu, 21 Mar 2024 11:06:43 +0100 (CET) Received: from wfhigh6-smtp.messagingengine.com (wfhigh6-smtp.messagingengine.com [64.147.123.157]) by mails.dpdk.org (Postfix) with ESMTP id 35EDB4029F; Thu, 21 Mar 2024 11:06:40 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.west.internal (Postfix) with ESMTP id 5AB3718000D5; Thu, 21 Mar 2024 06:06:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 21 Mar 2024 06:06:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1711015597; x=1711101997; bh=H4Z1YmbSfDksKs+xUZqFAl8COHg7uK5Nj2a4YK8eiw8=; b= Jz7fwoOmokI/WOjIbOvHaM0t8jECIdMLkJeT1Rzb6n+Q94hUgMyrVdDAt7sZwLKt hFunO+N1kwVBbeUsAOEnpg8jNYyd/UlJGGdMI0wKf0EsBvVgZs08BcZSkfXPXquZ WGuUYkHH4ZGR+sBHhT0B48Rg7V9I9fVQU93AfEXK4t49ZJRrqz7o8KBD7C4QNxHb 5sTzG6b1kk5lRz6LtARSvB3H5710gCeATbz83oCW+ToJKuApPeHlVA6fa5j2urvq unDNSyq6n1K+Q0QbYPmjhg1kv9UoMY4/cfGbYJWXg3W6gtVGFLpRNj1uUGPHDbH6 Lez2+OeYVJcpSsu4oYW9QA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1711015597; x= 1711101997; bh=H4Z1YmbSfDksKs+xUZqFAl8COHg7uK5Nj2a4YK8eiw8=; b=d hWcHejwsSDT0IZyol7EhpRCh7UokkAnR7L1Aeei2XiZbqszXQJ7jy+Kvrz0pktfq QTxa8FoDTvw71xMQBSk7n3dFjk9YV+6TucFfQ+cbZrw8NmXqhfI1Oz6g7XblSzlN zbLSVME9F0cZm+66qt6wzd1yhYh5ntloev794GQMmwsBjAmw6pV7S68TOesRDe6i JwEcrjlkRJjUhfuyx17yC2NpSB06Ry0ffDXueg54JW80HaR+RSt+NlMCebA1ixWk mhtVLvhOOoTPutahE3Og4d7OqXtQirDfKthVslYWeh93WORYAHaOp+mX1pqWqLNE L498ObTrhKs/5AKMwdsPw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrleeigdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepleejiedtfeehtedvvddvteejvdeluefftdehledujeefkeeiheej uefhheefteelnecuffhomhgrihhnpegtphhprhgvfhgvrhgvnhgtvgdrtghomhenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshes mhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 Mar 2024 06:06:36 -0400 (EDT) From: Thomas Monjalon To: "fengchengwen@huawei.com" , "Ma, WenwuX" Cc: "dev@dpdk.org" , "Jiale, SongX" , "stable@dpdk.org" , Tyler Retzlaff , david.marchand@redhat.com, bruce.richardson@intel.com Subject: Re: [PATCH v3] dmadev: fix structure alignment Date: Thu, 21 Mar 2024 11:06:34 +0100 Message-ID: <7851657.gsGJI6kyIV@thomas> In-Reply-To: References: <20240308053711.1260154-1-wenwux.ma@intel.com> <2631241.9Mp67QZiUf@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org 21/03/2024 10:18, Ma, WenwuX: > From: Thomas Monjalon > > 21/03/2024 02:25, Ma, WenwuX: > > > From: Thomas Monjalon > > > > 20/03/2024 08:23, Wenwu Ma: > > > > > The structure rte_dma_dev needs to be aligned to the cache line, > > > > > but the return value of malloc may not be aligned to the cache > > > > > line. When we use memset to clear the rte_dma_dev object, it may > > > > > cause a segmentation fault in clang-x86-platform. > > > > > > > > > > This is because clang uses the "vmovaps" assembly instruction for > > > > > memset, which requires that the operands (rte_dma_dev objects) > > > > > must aligned on a 16-byte boundary or a general-protection > > > > > exception (#GP) is generated. > > > > > > > > > > Therefore, either additional memory is applied for re-alignment, > > > > > or the rte_dma_dev object does not require cache line alignment. > > > > > The patch chooses the former option to fix the issue. > > > > > > > > > > Fixes: b36970f2e13e ("dmadev: introduce DMA device library") > > > > > Cc: stable@dpdk.org > > > > > > > > > > Signed-off-by: Wenwu Ma > > > > [..] > > > > > - size = dma_devices_max * sizeof(struct rte_dma_dev); > > > > > - rte_dma_devices = malloc(size); > > > > > - if (rte_dma_devices == NULL) > > > > > + /* The dma device object is expected to align cacheline, but > > > > > + * the return value of malloc may not be aligned to the cache line. > > > > > + * Therefore, extra memory is applied for realignment. > > > > > + * note: We do not call posix_memalign/aligned_alloc because it is > > > > > + * version dependent on libc. > > > > > + */ > > > > > + size = dma_devices_max * sizeof(struct rte_dma_dev) + > > > > > + RTE_CACHE_LINE_SIZE; > > > > > + ptr = malloc(size); > > > > > + if (ptr == NULL) > > > > > return -ENOMEM; > > > > > - memset(rte_dma_devices, 0, size); > > > > > + memset(ptr, 0, size); > > > > > + > > > > > + rte_dma_devices = RTE_PTR_ALIGN(ptr, RTE_CACHE_LINE_SIZE); > > > > > > > > Why not using aligned_alloc()? > > > > https://en.cppreference.com/w/c/memory/aligned_alloc > > > > > > > > > > > because it is version dependent on libc. > > > > Which libc is required? > > > > using the 'man aligned_alloc' command, we has the following description: > > VERSIONS > The functions memalign(), valloc(), and pvalloc() have been available in all Linux libc libraries. > > The function aligned_alloc() was added to glibc in version 2.16. released in 2012-06-30 > The function posix_memalign() is available since glibc 2.1.91. I think we could bump our libc requirements for these functions. I understand there is also a concern on Windows, but an alternative exists there. We may need a wrapper like "rte_alloc_align".