From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id 780FE1AFEE for ; Sat, 19 May 2018 03:35:43 +0200 (CEST) Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4J1Xfcv010794 for ; Fri, 18 May 2018 21:35:42 -0400 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j292vaen6-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 18 May 2018 21:35:42 -0400 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 19 May 2018 02:35:39 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Sat, 19 May 2018 02:35:36 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4J1ZZCm3670272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 19 May 2018 01:35:36 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EC0C011C050; Sat, 19 May 2018 02:26:47 +0100 (BST) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA88B11C04A; Sat, 19 May 2018 02:26:46 +0100 (BST) Received: from [9.124.221.108] (unknown [9.124.221.108]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Sat, 19 May 2018 02:26:46 +0100 (BST) To: Thomas Monjalon Cc: dev@dpdk.org, Anatoly Burakov , chaozhu@linux.vnet.ibm.com, pradeep@us.ibm.com References: <3666379.S78H0t7kV9@xps> From: gowrishankar muthukrishnan Date: Sat, 19 May 2018 07:05:34 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3666379.S78H0t7kV9@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-TM-AS-GCONF: 00 x-cbid: 18051901-0012-0000-0000-000005D83989 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18051901-0013-0000-0000-000019556FE7 Message-Id: <3107299e-f794-7caa-d39f-656b4a0c0b7c@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-18_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805190016 Subject: Re: [dpdk-dev] [PATCH 0/2] eal/malloc: fix wrong heap initialization over multiple memsegs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 01:35:44 -0000 Hi Thomas, On Friday 18 May 2018 06:40 PM, Thomas Monjalon wrote: > Hi, > > What is the status of DPDK 18.05 on IBM POWER? > > This patch suggests there are some issues but there were no news for > two weeks, after comments from Anatoly. > Are we going to release a DPDK which does not work well on POWER? This issue is not applicable in v18.05 onwards (due to memory rework changes there). Apologies for no update meanwhile, I will check on Anatoly's comments and get back. My idea is to address this before next candidate ready on LTS releases (v17.11, v16.11). Regards, Gowrishankar > > 03/05/2018 12:11, Gowrishankar: >> When there are multiple memsegs (each per hugepage), there are couple of >> problems observed: >> >> 1. Same heap size index is always chosen to add new malloc_elems >> again and again, while there is an increasing heap size actually. >> Hence, when there is memalloc request for size *more than* >> elem->size available in free heap, malloc_heap_alloc would fail. >> In elem_start_pt(), we are actually relying on elem->size at the >> best, for finding suitable element, which is lower than requested >> size, in this case. >> >> Hence, patch 1 in this series addresses this by merging >> contiguous malloc_elem (by virt addresses), so that there is >> better chance of finding suitable elem for the requested size. >> >> 2. Even after resizing the heap malloc_elems, its free_head index >> is still the same, as the memsegs are just added in every malloc_ >> elem. If larger memory is requested in rte_malloc, in a way >> that, heap index of requested size is beyond the slot where the >> entire heap is available, malloc_heap_alloc would fail. >> Because, at the time of heap init, only the lower index is >> always chosen to fill up memsegs. Hence, patch 2 addresses this >> by moving the list of malloc_elems into new slot in heap, as its >> size grows. >> >> We encountered these situations as we run ip_reassembly example app, >> when multiple segments are created in VA (when overcommit hugepages set >> in powerpc arch). >> >> These problems are found only in the current releases (until v18.05 >> which carries new implementation for dynamic memory allocation). >> These patches are tested with unit tests as well as some of the >> examples apps. I request more testing if possible, on other archs >> as these are problems in available LTS codes as well. >> >> Signed-off-by: Gowrishankar Muthukrishnan > >