From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id DEDE1A04F5 for ; Fri, 20 Dec 2019 17:55:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C2F472C60; Fri, 20 Dec 2019 17:55:43 +0100 (CET) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by dpdk.org (Postfix) with ESMTP id 5E6E3F90; Fri, 20 Dec 2019 17:55:40 +0100 (CET) Received: by mail-io1-f67.google.com with SMTP id v18so10070725iol.2; Fri, 20 Dec 2019 08:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1VZMsFaFx/4hqosetDYnjS14wux0IMNChcrsY8qyLNM=; b=HACX2cynn2CaBzIvmmLEFf14+rZbE2y/n8VYI3icajq4c/EpwV1MTvBsuP8Y18hceE C/HT6P9ExvOgr4U1LR5pFPk+klciRXVQUtTzF1aHw/1WiVpLUFFQ+w+O5U3/DUwxHPOo /yvmgDHVRrPKhsCESsZESz90zcX8YmqMwxYJ+NFY1rIuV6pUOBBZtwwEW/mFrgh55xbL DN8PLpbVnc1zJeGHuXv6Iycu3cVi4CblVfcaofcAI7ttD5NZ9/HCikfUdkXHyBTN05CA zcEo69d0D2VtRkDh957DLwN60rm5EjdNYbUA25MIzO14ggCHPnCUc5qWIxL3ZPYumVvc 2LhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1VZMsFaFx/4hqosetDYnjS14wux0IMNChcrsY8qyLNM=; b=LC/kXjpOolCspXuUk67SOIJt50nkaVKqnhj8wkBAtE9FeuKfDUKpw3j/y93P98GH9a liolLOaU8WVrsCbtrD4i42geXHahBkRKixHVxA+Zv+K2Ero3TtfOLOjfsyPhWRzQRMM6 5Em0y9sKdgRITXGqfvuRgCDBgrHV1qgcm/NjTi1Uzeq6fbxXKpUA1w2eV4Qo0eR4MqFT LApRjA+rf0CN2cNFOBYRlGHZW0pvj2lkpg3VkJFInWXSp8Lz3g6KrXIn2nnFfp7xdYQV g8Z2UoVBWUL7U0qL05KuGUZF8xm3CUfq7RxC476LvxdStysrIznFM27BpOJ0meev9OYw rj0g== X-Gm-Message-State: APjAAAU6gnooDr0Yh2PBJOXs2dWzWvD+mhkd/c0N5UU09tY5qKmwO+YT qVe9d6BKboU1f/8jEf5yGDNEEO6ySFAd3k1b2W8= X-Google-Smtp-Source: APXvYqz+kdSCZZcdMKq+woW3f3P4owHYzPEqvEn8b7XqtIyVBtIUJRa7aPk2TK6c6JzP1SmbPmKw4KX987xBvXBfM04= X-Received: by 2002:a5d:8cce:: with SMTP id k14mr1827107iot.294.1576860939506; Fri, 20 Dec 2019 08:55:39 -0800 (PST) MIME-Version: 1.0 References: <20191219134227.3841799-1-jerinj@marvell.com> In-Reply-To: From: Jerin Jacob Date: Fri, 20 Dec 2019 22:25:23 +0530 Message-ID: To: Honnappa Nagarahalli Cc: "jerinj@marvell.com" , "dev@dpdk.org" , "thomas@monjalon.net" , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "bruce.richardson@intel.com" , "konstantin.ananyev@intel.com" , "hemant.agrawal@nxp.com" , "shahafs@mellanox.com" , Gavin Hu , "viktorin@rehivetech.com" , "drc@linux.vnet.ibm.com" , "anatoly.burakov@intel.com" , "stable@dpdk.org" , nd Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] mempool: fix mempool obj alignment for non x86 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 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 Sender: "stable" On Fri, Dec 20, 2019 at 9:25 PM Honnappa Nagarahalli wrote: > > > > > > > From: Jerin Jacob > > > > The exiting optimize_object_size() function address the memory object > > alignment constraint on x86 for better performance. > > > > Different (Mirco) architecture may have different memory alignment > > constraint for better performance and it not same as the existing > > optimize_object_size() function. Some use, XOR(kind of CRC) scheme to > > enable DRAM channel distribution based on the address and some may have > > a different formula. > If I understand correctly, address interleaving is the characteristic of the memory controller and not the CPU. > For ex: different SoCs using the same Arm architecture might have different memory controllers. So, the solution should not be architecture specific, but SoC specific. Yes. See below. > > -static unsigned optimize_object_size(unsigned obj_size) > > +static unsigned > > +arch_mem_object_align(unsigned obj_size) > > { > > unsigned nrank, nchan; > > unsigned new_obj_size; > > @@ -99,6 +101,13 @@ static unsigned optimize_object_size(unsigned > > obj_size) > > new_obj_size++; > > return new_obj_size * RTE_MEMPOOL_ALIGN; } > > +#else > This applies to add Arm (PPC as well) SoCs which might have different schemes depending on the memory controller. IMO, this should not be architecture specific. I agree in principle. I will summarize the https://www.mail-archive.com/dev@dpdk.org/msg149157.html feedback: 1) For x86 arch, it is architecture-specific 2) For power PC arch, It is architecture-specific 3) For the ARM case, it will be the memory controller specific. 4) For the ARM case, The memory controller is not using the existing x86 arch formula. 5) If it is memory/arch-specific, Can userspace code find the optimal alignment? In the case of octeontx2/arm64, the memory controller does XOR on PA address which userspace code doesn't have much control. This patch address the known case of (1), (2), (4) and (5). (2) can be added to this framework when POWER9 folks want it. We can extend this patch to address (3) if there is a case. Without the actual requirement(If some can share the formula of alignment which is the memory controller specific and it does not come under (4))) then we can create extra layer for the memory controller and abstraction to probe it. Again there is no standard way of probing the memory controller in userspace and we need platform #define, which won't work for distribution build. So solution needs to be arch-specific and then fine-tune to memory controller if possible. I can work on creating an extra layer of code if some can provide the details of the memory controller and probing mechanism or this patch be extended to support such case if it arises in future. Thoughts? > > > +static unsigned > > +arch_mem_object_align(unsigned obj_size) { > > + return obj_size; > > +} > > +#endif > > > > struct pagesz_walk_arg { > > int socket_id; > > @@ -234,8 +243,8 @@ rte_mempool_calc_obj_size(uint32_t elt_size, > > uint32_t flags, > > */ > > if ((flags & MEMPOOL_F_NO_SPREAD) == 0) { > > unsigned new_size; > > - new_size = optimize_object_size(sz->header_size + sz- > > >elt_size + > > - sz->trailer_size); > > + new_size = arch_mem_object_align > > + (sz->header_size + sz->elt_size + sz->trailer_size); > > sz->trailer_size = new_size - sz->header_size - sz->elt_size; > > } > > > > -- > > 2.24.1 >