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 2ECC4A00BE; Wed, 30 Oct 2019 19:02:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5EA4E1C0C0; Wed, 30 Oct 2019 19:02:30 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 457071C0BC for ; Wed, 30 Oct 2019 19:02:28 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9UHkMAI020409; Wed, 30 Oct 2019 11:02:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=7bSbFF6bIijYhThBQTI2XtUzwtUNqtPDCgmStK0+utM=; b=R7SjF5gYdGhKYXh9a4axUNpYaHQXBemoZA/GL0/Tlz7XImR//evDi9MaeDjSWMpXHt38 WK+dMYvDfaDxHyK0maNxJid2epCb098ZkAR00v6KNMk+VJknO3gVSwSM9C9cIjqRhqns ba7WWOEMEnybf7QDp/p6tkfObGUXMAM9nI08K3wtgYTPI69NodbcLX7wsK8F4s4qlMEI e2FMcX+gtd4GebTgkOW93NV9bDXk9jJ7YWpKnolzUZnPIyxle8mQ4803RKx3CGg1jbWB yM6p4nep2CasJj5Oxf/hnms1lmZdtReFpbVBCEeEb46LT9XhuwR7iWaLV+sTOtmkIt16 CQ== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2vxwjm3unm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 30 Oct 2019 11:02:20 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 30 Oct 2019 11:02:19 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.53) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 30 Oct 2019 11:02:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A9MfJHIJaM+eXRAXfC18w5OQkvTWXve8a+KJeW5wQljqyATUi6dIV6TqchyDqmklE58Irv99U9pb2IEWSXAU43rda9w1MylFkCUmmiqCmRStgaycHEi598wrnLfGGPSpyk3ACAr3qKF+SKS2Es7ouDNcb2sw1DJFnxJykzjvDUPamfVZJ+i90smDwIN8AwzCJQav2supxRV3gjEeO1f9Iz8bHuWLGW1Fw48PoYuEzvk1wSJGcc7uA+Qg0JMKsK3szKqJi5JaKc9PIJnePq5AvtW64sPJ+ZB2fDdI7pZz9hajSuYPmRrkzUOLLPxcXNyOoknLb+TvPb6cA3p70UpMlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7bSbFF6bIijYhThBQTI2XtUzwtUNqtPDCgmStK0+utM=; b=cnv7s62GMvzw2n14RdQswjwMfxG9YNMMCpPZOngtWFHijFxBFXf64NVELKTax3o1+M3XNugiUQSJYEzH+1pVbyEifYJ2fc0DEyYxXSSmbU5WlrbL/ARivRpC6VHkFyGt+EtdNt8ylxHnkX6zsi2VQFcs0iQ1pp6v4CPtHEwFS0ntwJ90AryNMrKpzwmgy3ummrg1Cs/zw+2vNTEBZv/OuDb7ie5ycLieoe7ckYJndU/VNK1nGajxh5ZQ3NFIC2JwnZdVx+28+R7KLsRMcS1BHUY2WTt1GDcYwb4ry64zjUr65iDowAdEIGsszTMeKpp3UBXASz4igvN6DZ88iZsVwQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7bSbFF6bIijYhThBQTI2XtUzwtUNqtPDCgmStK0+utM=; b=fQTMUYNrs4UKiWAQcYJdj0ekKMS++mnWxRZ/y1mzoMT5pcOtDaYYjKNfNVGnEkqrx/rG2AlQ8Obz1eLbhxEmmgDaIJU9xpbGICWkOk5cy+iNzx3M8Xm4d2CwLK4gHAKCBOAvOz5FnFAbB0IllTFz0rUcWWeoi35etnc8zOK7+IU= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2760.namprd18.prod.outlook.com (20.179.57.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.17; Wed, 30 Oct 2019 18:02:16 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::c9e7:5cd0:547a:6de2]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::c9e7:5cd0:547a:6de2%3]) with mapi id 15.20.2387.028; Wed, 30 Oct 2019 18:02:16 +0000 From: Jerin Jacob Kollanukkaran To: "dev@dpdk.org" CC: Olivier Matz , Andrew Rybchenko , David Christensen , "bruce.richardson@intel.com" , "konstantin.ananyev@intel.com" , "hemant.agrawal@nxp.com" , Shahaf Shuler , Honnappa Nagarahalli , Gavin Hu , "viktorin@rehivetech.com" , "anatoly.burakov@intel.com" Thread-Topic: Mbuf memory alignment constraints for (micro)architectures Thread-Index: AdWPS2iWx/Kv7sS0Txqhe4GeZ0d67A== Date: Wed, 30 Oct 2019 18:02:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [106.200.247.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7a7602a-06c9-4d80-9084-08d75d634c6a x-ms-traffictypediagnostic: BYAPR18MB2760: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(199004)(189003)(476003)(2501003)(6506007)(86362001)(966005)(6916009)(256004)(6306002)(99286004)(5640700003)(486006)(26005)(9686003)(76116006)(54906003)(186003)(4326008)(66946007)(55016002)(14454004)(2906002)(6116002)(7416002)(305945005)(66476007)(71200400001)(52536014)(102836004)(66556008)(2351001)(6436002)(8676002)(1730700003)(81156014)(66446008)(7736002)(64756008)(81166006)(74316002)(71190400001)(5660300002)(25786009)(66066001)(33656002)(3846002)(498600001)(8936002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2760; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:3; MX:3; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ugkFn8GHWJnSMhgqnFyiVuNHsvGtgBZLI0TSfcr62M+CK3HjG/eNAHhUNXgad4DFXjM1vzBL1NJyv2zBECKNwtVUkNwBAyPnQE6NIDRBT0SGknB/qVHgcHEAYxrTdV4dtUlhauBWJfRdOxNzIaeIjzLiDgo7B8vGI40m+b113qBL2J5ZeykL8tywt3rj5x/AgKHrdJPqQJsJvrTNEz02UySm1wC6J5mQ1SqBeTN3lIBA6uEDB20828zo4kdcD54VW361ProLwfRYRYGOnEllxvboQbc1HKoAQlDVZSISAs0Zpbe7uUbmhzp2/Mk9lZop544zJZqgYGyS0kkxnwsKfptReGYUk0Joe2s5rGHhwVGij+sHD7/Z8IqaqkID6evJaVKk9mIughWG1x6PNjT+uOTAB6T6FugP+gnt6PUVApaMqxxvQUqH0FOvpwUT7X0jTc7hdqwk9dhPKc8nv9WOCHEzQy+DkLD9qjAd6LvVbpY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a7a7602a-06c9-4d80-9084-08d75d634c6a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2019 18:02:15.9463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OCDo99VoZVYTLJokyAi1cC6gsZsE/9KL/bOyfkDF2LSMcuQcoFrTL3bi1muRbw2FL1e1Zp0ZA4Q8RPV+VX3dSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2760 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-30_08:2019-10-30,2019-10-30 signatures=0 Subject: [dpdk-dev] Mbuf memory alignment constraints for (micro)architectures 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" CC: Arch and platform maintainers While reviewing the mempool objection allocation requirements in the code,= =20 A) it's found that in the default case, mempool objects have padding=20 in the object trailer to have start addresses of objects among the differen= t channels, to enable equally load on the DRAM channel to have better performance # More documentation is here https://doc.dpdk.org/guides/prog_guide/mempool_lib.html in section 8.3. Memory Alignment Constraints B) The optimize_object_size() does the channel distribution requirement by the following formula new_obj_size =3D (obj_size + RTE_MEMPOOL_ALIGN_MASK) / RTE_MEMPOOL_= ALIGN; while (get_gcd(new_obj_size, nrank * nchan) !=3D 1) new_obj_size++; C) The formula mentioned in the (B) is NOT generic. At least of the octeont= x2 SoC The memory/DDR controller works in different way. Where by: # It does XOR operation of some of physical address lines(not the user spa= ce VA address) to compute the hash and that the function defines the actual channel. The XOR(kind of CRC) scheme is useful because there is natural channel dis= tribution based on the address i.e No need to have padding to waste memory So, in short the padding scheme does not need for some SoC. I trying to sen= d the patch to fix it. So the questions is, # Is PPC and other ARM SoC has formula (B) to compute DRAM channel distrib= ution ? or Is it specific to x86? That would define where the hooks needs to added to = have proper fix.