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 9DFED43D17 for ; Thu, 21 Mar 2024 17:05:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 963F1427E1; Thu, 21 Mar 2024 17:05:31 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 625FA4029E; Thu, 21 Mar 2024 17:05:29 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 818BB20B74C0; Thu, 21 Mar 2024 09:05:28 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 818BB20B74C0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1711037128; bh=dvL0vpGoVJPwl0v+O9+wqHqGWrc2w7UTfycDjJr5SBE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QdWhNknQTvx51C59e9fUrvI6opBfng3L7aGldW3ZgEyTFjdP2+sKjZNRvlus6llhS aOjllYbsD6WAfpLDWFZycyN4G/j9um0oIlMkIX9hSHDA6qmq+rd5fV1VwA8c1tzo+i a5LEcci2LX05vdEAjjmmvt9dC6jHPs2WGfJC5U1s= Date: Thu, 21 Mar 2024 09:05:28 -0700 From: Tyler Retzlaff To: Thomas Monjalon Cc: "fengchengwen@huawei.com" , "Ma, WenwuX" , "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 Message-ID: <20240321160528.GB11257@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240308053711.1260154-1-wenwux.ma@intel.com> <2631241.9Mp67QZiUf@thomas> <7851657.gsGJI6kyIV@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7851657.gsGJI6kyIV@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) 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 On Thu, Mar 21, 2024 at 11:06:34AM +0100, Thomas Monjalon wrote: > 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 If we are using C11 we probably already implicitly depend on the glibc that supports aligned_alloc (introduced in C11). > > > 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". Yes, I'm afraid we would probably have to introduce rte_aligned_alloc/rte_aligned_free. On Windows this would simply forward to _aligned_alloc() and _aligned_free() respectively. ty