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 9F4C843E53; Fri, 12 Apr 2024 21:04:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2A105402A8; Fri, 12 Apr 2024 21:04:19 +0200 (CEST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2078.outbound.protection.outlook.com [40.107.212.78]) by mails.dpdk.org (Postfix) with ESMTP id EE31840299 for ; Fri, 12 Apr 2024 21:04:17 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UyrilnR7DT2RYbMp3XPeaEekcpKHLpO08DjmsNNgnvE7KktLydL8OvpKJN+nMJySZItsovx1EEsygqezeY8oIZ4yVpSMsSBOmG9ipbHCmIhmkpHaqb4oWVFs7tRxilJq+AxbJVRRQZabVqYhNpQHlDPABoMqApZY2uYkS1pfklUi5vhHzatao8qHSFGFZ4tw6rjSWLnLfJIJEWeWKFUGq5fll/12jrv2sw8+TaNFKG98Wf9fCjFYGWAitGQvkXS4pZsK+JimOcfXldkG3PFPz7ITpRBC6+RX+05Ema0OVfmoaRaw36LgLx5tqHlmoje0KzJvC7QpPDIPMzTUx/R3sw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HGVzZZBDgfktRUWDqZbU+F0KxbgSs4ObnDy018X2508=; b=gLGFhJrYNXUpfQmPhQphPWuRvIvUKQWKkX4iLKsD7kYpBuKwsUJ665giiWkC0EL3yRepT05OIY3GIhmHZsyOWKcwfiI6KmCgGkXe1by7owvuwqX9f6C4f6k+pI3NqqarVea4E0gLT8KvKPlubgeMTpjXHaDfC5yNhZDsbCMvBeLY9tXJyJCUPtCIWVU0MZVscwWGh0x0amxdWsqw5FuRgdOWD2qcd1JglVYHCLCLjUfFgpYKglILOIJgvQ/fq2wgXpRTCK0ryxwwVJHc9dP5YGVl1l7dqEQtDudHaGoY9HoiKkeDnnhmjc5zZLDMxh6rnSkEfMYypzLd9ZsXxkIJyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HGVzZZBDgfktRUWDqZbU+F0KxbgSs4ObnDy018X2508=; b=GKpuZWmNOv8JSTffc9bTHU74giJpQsWmySLz3pNh9azazZIuhz8J9tkjChog6p9iBgW2w8k/b9zCPyDaUsXO7Es2o2NJALjjoSF7x6j2XtOpRVVCi3StLgiwZid31dwtTTwrJxNo9A19thrmnvYDUiMz9G9Ey+nfgC66SleuOus= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by PH0PR12MB8007.namprd12.prod.outlook.com (2603:10b6:510:28e::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.54; Fri, 12 Apr 2024 19:04:15 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::282f:29d3:cac1:cde3]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::282f:29d3:cac1:cde3%7]) with mapi id 15.20.7409.053; Fri, 12 Apr 2024 19:04:15 +0000 Message-ID: <1c487911-d7a4-44dd-be1a-4813fe1f0f36@amd.com> Date: Fri, 12 Apr 2024 20:04:09 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7] net/bonding: another fix to LACP mempool size To: Gaoxiang Liu , chas3@att.com, humin29@huawei.com Cc: olivier.matz@6wind.com, dev@dpdk.org, liugaoxiang@huawei.com, =?UTF-8?Q?Morten_Br=C3=B8rup?= References: <20220325133426.2916-1-gaoxiangliu0@163.com> <20220328151652.221-1-gaoxiangliu0@163.com> Content-Language: en-US From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@amd.com; keydata= xsFNBGJDD3EBEAC/M7Tk/DfQSmP1K96vyzdhfSBzlCaGtcxNXorq4fALruqVsD3oi0yfyEz9 4YN8x7py0o9EL8ZdpOX0skc0AMCDAaw033uWhCn0GLMeGRKUbfOAPvL6ecSDvGD7CJIO9j0J eZUvasBgPdM/435PEr9DmC6Ggzdzt8IuG4PoLi5jpFSfcqxZFCCxLUDEo/w0nuguk2FTuYJg B2zEZ4JTBZrw7hIHiFh8D8hr6YA6a5uTofq1tr+l048lbtdFUl8TR0aIExVzE4Z8qKZlcE+9 RQaewjK5Al1jLE4sHdmd3GN+IvgDF3D/fLsi25SKJDeGSdeHkOmaX0qGeM4WKIfU6iARRCiQ N3AmBIxZ/A7UXBKLaOyZ+/i3sE6Wb53nrO4i8+0K2Qwyh6LjTeiJAIjYKN43ppxz3DaI+QwQ vI+uyHr4Gg0Da9EPPz/YyKauSeOZCfCB5gIfICO0j6x0SCl8uQ2nLpjxcZkf0gjcwUzP3h+S 3x6NfDji9YEij0zczW/dcSpGgZ6vsFpPrtnP9ZXy6J53yp0kJtOJoOlkEFFdU2yCZnCDseum CoudmGLZVvS0/DzHDJejq+3kK3FDGktZBOxZIIpal+nFqS7lVgOZc4+huVv3jyhzoAUOEyXA XK5j6o7g8STUY+z33QNnHpdLvecMwuzmvqy0jR54yAbZ64mB9QARAQABzSNGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBhbWQuY29tPsLBlwQTAQgAQQIbAwULCQgHAgYVCgkICwIEFgID AQIeAQIXgAIZARYhBEm7aYjps5XGsPHCElRTPtCKKm/6BQJkdyEEBQkE3meNAAoJEFRTPtCK Km/6UdcP/0/kEp49aIUhkRnQfmKmNVpcBEs4NqceNCWTQlaXdEwL1lxf1L49dsF5Jz1yvWi3 tMtq0Mk1o68mQ7q8iZAzIeLxGQAlievMNE0BzLWPFmuX+ac98ITBqKdnUAn6ig5ezR+jxrAU 58utUszDl16eMabtCu76sINL5izB8zCWcDEUB4UqM8iBSQZ7/a7TSBVS0jVBldAORg1qfFIs cGMPQn/skhy3QqbK3u3Rhc44zRxvzrQJmhY6T1rpeniHSyGOeIYqjpbpnMU5n1VWzQ4NXvAD VDkZ4NDw6CpvF4S2h2Ds7w7GKvT6RRTddrl672IaLcaWRiqBNCPm+eKh4q5/XkOXTgUqYBVg Ors8uS9EbQC/SAcp9VHF9fB+3nadxZm4CLPe5ZDJnSmgu/ea7xjWQYR8ouo2THxqNZtkercc GOxGFxIaLcJIR/XChh9d0LKgc1FfVARTMW8UrPgINVEmVSFmAVSgVfsWIV+NSpG9/e90E4SV gMLPABn1YpJ8ca/IwqovctqDDXfxZOvCPOVWTzQe/ut767W+ctGR1kRkxWcz470SycOcY+PW VRPJd91Af0GdLFkwzZgNzkd6Gyc9XXcv4lwwqBLhWrBhqPYB0aZXIG1E/cVTiRp4dWpFHAFD DcuLldjIw93lCDsIeEDM9rBizGVMWEoeFmqSe7pzGTPXzsFNBGJDD3EBEAC8fBFQHej8qgIG CBzoIEd1cZgPIARlIhRudODXoNDbwA+zJMKtOVwol3Hh1qJ2/yZP11nZsqrP4fyUvMxrwhDe WBWFVDbWHLnqXMnKuUU1vQMujbzgq/4Rb9wSMW5vBL6YxhZng+h71JgS/9nVtzyaTtsOTrJi 6nzFSDx6Wbza2jYvL9rlK0yxJcMEiKwZQ/if4KcOesD0rtxomU/iSEv6DATcJbGXP6T93nPl 90XksijRKAmOwvdu3A8IIlxiSSVRP0lxiHOeR35y6PjHY2usfEDZZOVOfDfhlCVAIBZUZALv VmFOVSTYXeKgYa6Ooaf72+cHM3SgJIbYnevJfFv8YQW0MEAJ/IXE7B1Lk+pHNxwU3VBCrKnA fd/PTvviesuYRkrRD6qqZnINeu3b2DouVGGt2fVcGA38BujCd3p8i7azoGc7A6cgF7z9ETnr ANrbg1/dJyDmkDxOxVrVquTBbxJbDy2HaIe9wyJTEK2Sznpy62DaHVY+gfDQzexBXM10geHC IIUhEnOUYVaq65X3ZDjyAQnNDBQ4uMqSHZk8DpJ22X+T+IMzWzWl+VyU4UZXjkLKPvlqPjJk 1RbKScek5L2GhxHQbPaD76Hx4Jiel0vm2G+4wei8Ay1+0YRFkhySxogU/uQVXHTv63KzQMak oIfnN/V2R0ucarsvMBW+gwARAQABwsF8BBgBCAAmAhsMFiEESbtpiOmzlcaw8cISVFM+0Ioq b/oFAmR3IPsFCQTeZ44ACgkQVFM+0Ioqb/qINhAAtcor9bevHy22HvJvXX17IOpPSklZJAeQ Az43ZEo5kRlJ8mElc2g3RzYCvL/V3fSiIATxIsLq/MDtYhO8AAvklxND/u2zeBd7BkRZTZZX W1V1cM3oTvfx3LOhDu4f2ExQzCGdkzbXTRswSJIe1W0qwsDp+YPekbrsKp1maZArGeu+6FuW honeosIrWS98QJmscEhP8ooyJkLDCCOgEk+mJ/JBjzcJGuYn6+Iy/ApMw/vqiLGL1UWekcTA g18mREHqIR+A3ZvypIufSFB52oIs1zD/uh/MgmL62bY/Cw6M2SxiVxLRsav9TNkF6ZaNQCgn GqifliCEMvEuLZRBOZSYH2A/PfwjYW0Ss0Gyfywmb2IA990gcQsXxuCLG7pAbWaeYazoYYEQ NYmWatZNMAs68ERI2zvrVxdJ/fBWAllIEd0uQ4P05GtAHPdTIDQYp545+TPV7oyF0LfXcsQs SFVZE6igdvkjfYmh+QOrHGZvpWXLTmffVf/AQ81wspzbfxJ7sYM4P8Mg5kKOsaoUdyA/2qVe cMh1CLUHXF1GlofpGbe1lj4KUJVse5g3qwV7i9VrseA8c4VIZewdIjkzAhmmbxl+8rM/LKBH dZUMTzME5PFCXJIZ83qkZQ795MTe2YScp9dIV7fsS5tpDwIs7BZNVM1l3NAdK+DLHqNxKuyO 8Zk= In-Reply-To: <20220328151652.221-1-gaoxiangliu0@163.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LNXP123CA0006.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::18) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|PH0PR12MB8007:EE_ X-MS-Office365-Filtering-Correlation-Id: 822c580b-a535-473e-18c8-08dc5b235834 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2shy3MhUvoWR5hFKjeOM4hWVHYPwggH/ZAdMrpuQCbg+E6UnvyfAIrz72RoRW/j+3wLmO9FRkoSGEV/M8LgCI+Q8BoAn/KLEiiygq00FwuKsGzaHx24SzlUUwnzQ5MPes1kgxUn95+lACWLvmITuq8PAGDknepuRK5iu8abJqIIZi310clbJhxVruIx1v46TgR5h96IducAVV8rVpBhpQq9GZJ4bepvFTA2RNpo4kxxUqpQ1GKyBGxXqHqKQos1s7jOeYJ8D/yjnGGRneyUhtsIV4II+PnS8KKiIJs4JR0H+nXstzXjmcGNSAMRuUU8ZbFGAJZPxg7PWpVyRl2qXas/5ChzcedK/DwbfLcGmJmFggurmcb45tPV1tPurjXHfcsyOqjkkUDAm1in+RzVVtxeYZdtdsg2wUd1TwYmRwtG1WsIQlDW+qNgwfzXCMEShM9auOBRnu52vcCmA6iJxmO9Z+3xzRfjwlCaZmixkQ999D8dIvkmZ7ET1bsTlYhgA6klIFFy5pQCRXbSxPTuo3a6ayjW7oWMSwCd3ucPJUZwCN4Nc4dNfMz1+AqnQa/TuIanBkCSosqnZCrXUq5X41YZql12yoODN7adzOlCJ78Ch8XliXQoc8MpDoWFFCakcE7KLyKL4WvWN3Bk3K0JIfnfhSRNZoljggReOtQbKHXk= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(366007)(1800799015); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K2xUUTAzZS9jUndIekRWVWw0UEtJcmw3TFpJQmVjY0hTUmwwYjFhdlo5WGVR?= =?utf-8?B?em9tWk4wZnR6dDdBWEhxWlRpMGszYlp2bWVSVTdmUjJIaHFoTEh2TUROYVNC?= =?utf-8?B?Qy9kZ2E2QzBxQlNyWEVlZ05SVU5LSWxvdnJmc2hpUXBSQ2RkOHFicnBxUDFB?= =?utf-8?B?R3IzUDZURDJIV3pFNDdGeUtuVzZhRU9tZmIyQ1MwTXQ4N1phT3BLVjRRcG8x?= =?utf-8?B?N1ZOcW5aRWdWeGdJMDlNWWJsQi9qNjI5TktGU2ZDVFA2VktLbnRIbHpXaXha?= =?utf-8?B?SnhaTWQ5bDRyQVdkK1IzemFKUWI2SE9YaXlMd0pqMW83OE95S3ZsMXVNZTI0?= =?utf-8?B?bzZlTVc4R1ZkUTdDL1I3SnBDbmwxQWZZaUtqblA5cVRvenI5TlhybnJxSjdV?= =?utf-8?B?dnVUNUNBVWlyQUdGaGJtZ0pmR0pIcllHYVluZUdiaklmcFV4dW51bmlpY3px?= =?utf-8?B?MmFZYmkxU0FXbmYyZk8vYjU4WEJvQTFycG9qRFlnV3E2c1RJZC84c1A3NG9U?= =?utf-8?B?RTdWL1Vrc0NadkFFTjFYdldRelJOZkJjVUhmMGN1RFhIL2NncCtzMFB6akE2?= =?utf-8?B?TzgraDB3bnhmeXVBL1FPTFhmVTExRmVvVFQ5amVQTHJkWHlMUUo1ZTY0ZkVr?= =?utf-8?B?YkFHbFY0bXE4NmpjUXBOcm5BZ1ZRYVQ4dkE4TEJGMUVqaS90cEJ2WmNEQ2tw?= =?utf-8?B?WE00ckNLQmg3aGhza0hyOWtKV2JLOHovSjI5K2ppdVhVUFhLRmhRSUM3aUZE?= =?utf-8?B?cjFGSG9tKzkzU1dCQTU3L2liMDk2UFVoUENjWDNicnc2VkZZVG9sejNnNDdI?= =?utf-8?B?bkp0aDkyd3FSc1N1N25FblpDSDM3T21Ub24zYUYvVmFleFQ0ZzBCK0RudCsy?= =?utf-8?B?bTJvNk1ONENDODBGNEFmd3JaWDBkSm5FNDJKYjJqSGtHOUVXTnl6NjVWL2p1?= =?utf-8?B?TnNLN0d0M3FGQVFJZVNLUll4QW56bUJJVU04SXNHVUFydWxFQmlXSzdhWnpB?= =?utf-8?B?L3puQ2hzcXhnUE9MVy9jRm1CNFlPalRaSm1zYUp3ajFFYzRGdldPcHR1K3V4?= =?utf-8?B?c0g4TGhpc2lYdUtPYUdid0RMS1A2Slk3MnJKa1BOT3UySFY0MUQzU05jdkFz?= =?utf-8?B?T1BNYWxOMkd5d3grMkRaY0Njb3BCd2t4TkxSb29tWTNoVkxGWjdWazRDMlVa?= =?utf-8?B?Sm8zTGtrUHJtZkJzbzJFMmxxRzZHcHJYQ1YxM0M0ZnJ3VEs5SjIwM2NQanIr?= =?utf-8?B?S2R0Yk5sUmsxVkQ2WlMvbmNjQ2NTanBLWTlOL2ordXFWdTRzQmVMRlZQbnhR?= =?utf-8?B?NGZ3VUlwNUc2RGkxczF0bjVKMGtQWHRLQ1BBUWhiQ2tlNTVqN2d2L2tFUXJw?= =?utf-8?B?MGVaNjZTOWdpNEpCRk9XMHUzRUdTWVF1Q2RyZ3c5OU8xMWdOd2xRT2p4WWNF?= =?utf-8?B?b3ZOM2RLZGZGMXNSMlBBSmFDMTVsaXdRZFgvZ0J6M0dvL2pkd2dSbktQbUNu?= =?utf-8?B?R29lWmZ1OGFSRVRER3UxNkwzZDdMN3RVZmxWV203ZjhYRWxIQTZDcEY3c2pu?= =?utf-8?B?YWxmR1Btd1JiUHZiaVRVMno0ZWJTcm5keWFsdVVSeWE4T3RGajlHM2JyQ2RN?= =?utf-8?B?Z1BJUjdNUzRoOHJHNE1nQUczbjJYa3I3RVZoczdMRmpxR240VHhVbHFlMnJa?= =?utf-8?B?bEQ0Q05zQWc3alFYSjJxV1VpNU9wVXBQdkhoZTNpSDdjbVFla3BKS2FnbVh6?= =?utf-8?B?alRTRzdJQVpFNU8wbUhNWDhKeXNUOE5aTDh0VUh0WUNYNThLdHNraXBwaGJY?= =?utf-8?B?Q3FhOTlKZUdqOWtORGNkOHpQbG1KbjlvVUFkazQ3em43OHgyQXhsSmIybUxZ?= =?utf-8?B?dFEyNCs1eVNDS1IxeUVjRTF2SXBIVjM3eUg1R2xkY1VCaFBUNTdwOTNZaWRH?= =?utf-8?B?bUloLzFxMEtsbGxiV0k0aVd2L2ZjRDUxV1pyR1RqbnEyYXJiMXl6djFhazZy?= =?utf-8?B?T0ZKMytzRFJpSkhSNUE2cWhDTXlLNXUzOWVJSHpXcWFxKzJ3Y0Rtb2owWHJm?= =?utf-8?B?WVBWRWxqaEVSM2lqcFUwMnBWdEI5NzI1eko0aG1uT2w4MnRXUmlWMDdUbVRJ?= =?utf-8?Q?6gZ+G/lA8NJRVcxqOV92AjA1l?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 822c580b-a535-473e-18c8-08dc5b235834 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2024 19:04:15.0070 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 6LnF2ztqoy/ICp75zp9boM3CFItuP0jPHNhy/0TR4WajD2Ng+8yy5Q5bUjqii3Qt X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB8007 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 3/28/2022 4:16 PM, Gaoxiang Liu wrote: > The following log message may appear after a slave is idle(or nearly > idle) > for a few minutes:"PMD: Failed to allocate LACP packet from pool". > And bond mode 4 negotiation may fail. > > Problem:When bond mode 4 has been chosed and delicated queue has > not been enable, all mbufs from a slave' private pool(used > exclusively for transmitting LACPDUs) have been allocated in > interrupt thread, and are still sitting in the device's tx > descriptor ring and other cores' mempool caches in fwd thread. > Thus the interrupt thread can not alloc LACP packet from pool. > Hi Gaoxiang, Briefly, this patch increases the mempool size, an additional amount to compensate cache size. Above mentions two reasons for increase, 1. mbufs in Tx ring of the device. As far as I can see mbufs allocated from 'mbuf_pool' and enqueued to device Tx ring, and if what I understand above is Tx queue may be disabled causing mbufs stuck in this ring. 2. mbufs stuck in mempool per core cache. Increasing mempool size can be an option but can we address root cause, for 1. if the device Tx queue is disabled can we skip enqueue to the ring. And for 2. as you said mbuf is allocated only in the interrupt thread which doesn't have any cache, so not sure why other lcore caches filled. Also can we disable the caches instead, as this is already used for low traffic? > Solution: Ensure that each slave'tx (LACPDU) mempool owns more than > n-tx-queues * n-tx-descriptor + fwd_core_num * > per-core-mmempool-flush-threshold mbufs. > > Note that the LACP tx machine fuction is the only code that allocates > from a slave's private pool. It runs in the context of the interrupt > thread, and thus it has no mempool cache of its own. > > Signed-off-by: Gaoxiang Liu > > --- > v2: > * Fixed compile issues. > > v3: > * delete duplicate code. > > v4; > * Fixed some issues. > 1. total_tx_desc should use += > 2. add detailed logs > > v5: > * Fixed some issues. > 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_eth_bond-8023ad.c > 2. use RTE_MIN > > v6: > * add a comment of CACHE_FLUSHTHRESH_MULTIPLIER macro > > v7: > * Fixed some issues. > 1. move CACHE_FLUSHTHRESH_MULTIPLIER to rte_mempool.h > --- > drivers/net/bonding/rte_eth_bond_8023ad.c | 7 ++++--- > lib/mempool/rte_mempool.h | 2 ++ > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c > index ca50583d62..f7f6828126 100644 > --- a/drivers/net/bonding/rte_eth_bond_8023ad.c > +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c > @@ -1050,6 +1050,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, > uint32_t total_tx_desc; > struct bond_tx_queue *bd_tx_q; > uint16_t q_id; > + uint32_t cache_size; > > /* Given slave mus not be in active list */ > RTE_ASSERT(find_slave_by_id(internals->active_slaves, > @@ -1100,11 +1101,11 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev *bond_dev, > total_tx_desc += bd_tx_q->nb_tx_desc; > } > > + cache_size = RTE_MIN(RTE_MEMPOOL_CACHE_MAX_SIZE, 32); > I can see it is coming from old code, but do you know why 32 selected as cache size, is it an arbitrary value? > + total_tx_desc += rte_lcore_count() * cache_size * RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER; > snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id); > port->mbuf_pool = rte_pktmbuf_pool_create(mem_name, total_tx_desc, > - RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? > - 32 : RTE_MEMPOOL_CACHE_MAX_SIZE, > - 0, element_size, socket_id); > + cache_size, 0, element_size, socket_id); > > /* Any memory allocation failure in initialization is critical because > * resources can't be free, so reinitialization is impossible. */ > diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h > index 1e7a3c1527..fa15ed710f 100644 > --- a/lib/mempool/rte_mempool.h > +++ b/lib/mempool/rte_mempool.h > @@ -56,6 +56,8 @@ > extern "C" { > #endif > > +#define RTE_MEMPOOL_CACHE_FLUSHTHRESH_MULTIPLIER 1.5 > + > I can see we delve into discussion related to this exposing this value from library, instead of having a copy in driver (which is valid point). Looking to the reason to usage, driver tries to compensate the mbufs may be may be stuck in the cache till they hit the threshold. But this flush threshold value can be driver internal, and it seems original intention is not have something driver/application be aware of this value. So instead of using this value, what about first try disabling cache as mentioned above?