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 9B89243DFA; Thu, 4 Apr 2024 16:28:38 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80A2A4025D; Thu, 4 Apr 2024 16:28:38 +0200 (CEST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2112.outbound.protection.outlook.com [40.107.237.112]) by mails.dpdk.org (Postfix) with ESMTP id CACC740150 for ; Thu, 4 Apr 2024 16:28:36 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DhIZmo/Vrw3K4XW3WtcUCRAv2/NlhrQPUW3NDAWL7E3g13p/hRuC29n0rD77yacHuvaoXjBlM+ZwkpZWprl/TAAfLh543F2fVeYsyAPDeWrC7WiCprpBwxzikYAZ5l3eFC2Ji5sadM+4wYq1K+yQCIqsjITM1d6x7c03veS1D/WetZZ1CekF44aWKCt2fMYxfct9k40TSjVNevPEW67l7slhHNoEH4OKSxnwbtOoe3JSikmUnSJ2Cdnmx0WVqF0yLlSVOzdxNT/DHXEVMFMmhi1VvCcFREnPI3mwq3ne4bD25ZkBIhByPnK9hmIg6M8AxJnqI65TMDKyR/M79s1d1A== 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=y7VIHQu2BKJvptumbJ8VitawvIQjKQ8qVQktUFTvkm4=; b=VyBuFLA+eDf10ociVFp+p9GgH/VcnKvhE1R/MnIzv1I2apaAKOI+SwcO+yTHU3Bw0YVgF1tKT6ENOrgQL0aJ6UAA9rMYp0lui1xxUuR5l3jlK2zwpn9MAbTM26LYEPnsZaRDRExZBHi8D1nRdQDhhncRVsKea3PX9Hidv3TMqMGmJ+dRUinxH1saMDNnVn4X4RL5jkfgp2WKMqAXbVykMY++b6wYPSKCB4f4JxDnZ69Bs/Cxv6E8IG1lPZxoxETDEgHoeutfnR25v7bnOTp7GK38Yroh6tm0GsrRoF+rL4MU+aYInveNK210KuZINQpCk/1WLpxeGP9hpOe0FaMHeg== 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=y7VIHQu2BKJvptumbJ8VitawvIQjKQ8qVQktUFTvkm4=; b=JvA1NdUFVGSLXs/CseTuidbeDrJi8XbQ2qxEH5hVNwQI38C3EwIAyShc6c2to9oxmlB5oQGUUAwMm9yX8Wv4A6P3HNdo5K9v4IoFTH4uQVnnPOOI1QxasWBX5rqwc2HwyqKrMMxP7/4u/qrJXdGIB1RvXQCdoDQW8m3KblT40ys= Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by MN0PR12MB5787.namprd12.prod.outlook.com (2603:10b6:208:376::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.45; Thu, 4 Apr 2024 14:28:34 +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.042; Thu, 4 Apr 2024 14:28:34 +0000 Message-ID: <4aee87dd-f4fd-4d74-b2e1-a3b7b195e41c@amd.com> Date: Thu, 4 Apr 2024 15:28:28 +0100 User-Agent: Mozilla Thunderbird Subject: Re: Issues around packet capture when secondary process is doing rx/tx To: Konstantin Ananyev , Stephen Hemminger Cc: "dev@dpdk.org" , "arshdeep.kaur@intel.com" , "Gowda, Sandesh" , Reshma Pattan References: <20240107175900.1276c0a5@hermes.local> <5c28d2a26f5142c3a509cc8bda2fca75@huawei.com> <20240109150611.00d13e13@hermes.local> <59dfbb6360104c348b4eb3dc767b0233@huawei.com> <6303f2bf-fc5c-46dd-bcac-f79c0c824a02@amd.com> <04daf6bc50184e9398f0a0ac0bc42759@huawei.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: <04daf6bc50184e9398f0a0ac0bc42759@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P265CA0237.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:315::20) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|MN0PR12MB5787:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I3nMVTLKdKXEAafkEf/whgXqYrfsufA1Y1W2fWj6YwIRl9fOMTk3m1pD7Vo1YrM2qSQs3sYiXUIa9r0YQ6WD2tSP2JZz+WbbuvqjEeTUZ40VamW46BE8pzVJwUSvAYF/748sznL6Yp3HEPKYkgVPRM/4RY2SJ5oSJKu0Uxr/HlrDrdUy+AY0u3UyT4Za+vIRbBjXjumu4o9sMCZ9WFH7/IJ1MltuNpyHS7rVr4oeK0OO+OeukyVxFT5LDld8Q4CW2ziw/gFUYxf67v9KU44V44LOzKKPs0ZKmYcjPaFRGVgvAht1DOtqditwAOdx8TNO/CVZ0oi0HzDYcTi0iVUpbnI64iUIwG7vPUiphdk+3bdAeW8sTnyhiAhNOrHHTfKoJ+lznAI9OTEkXARNMWTmZiBThXi/d8k3q5/yOz2RsYrTAWefWH+z+0/H+elpn/hu0Jkeanj26x5R8FcmDIbfghs18cAN2nh7Gq+gu20lLgXXPbES1U15slQYhpQtLeH1Zn2hzljL4JiJWidBUx5Xq3SpQKjM2xDRql4Lo9l/Yp95kR2HAru1c9yfGaP6XAoQTRqvCW120as4yhEkY4CRii0nfxfXqI+7BiDDeVMNhRFYfQOqrdIKtTbaS+XLKr5WX9CwVP6BdhyW8ruJrrf2v68lIIKh5A1UyZ9oRL3A4XI= 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)(366007)(1800799015)(376005); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RHdDZFNrTHpuS1NKeDNtTFp2QWV0MnVyYVpmT0VjSjFFdjROVllqLzU0S01T?= =?utf-8?B?VmcrR2lSTUNFaFU4TnA3RHR0cmhYejFpcENUWWtTdm9nYkFmRWUyeEcvTUZ4?= =?utf-8?B?cHVLc004bWl0elJwdzlvUytiV2tEWjJHN0p6NTI4MW80QmhDeXhuV3l4Rlc1?= =?utf-8?B?bEs2MnN1cXhWOENudGp6NlBDZEtxSTQ3MTBkWWNQTUhJTm0xZFJXeEsyUWxv?= =?utf-8?B?SzlPak5aL3dvam5GL3YyUzZMbHNDMk44R2xnQXhxY1ZTb3ptczB5b2FHd0po?= =?utf-8?B?cmlEOHdhUWQ2clZJYlkxSmRhaU1WMXJFYXFnVFExbmpKR2RKNFhscFBVWUdF?= =?utf-8?B?QmJHUlh1Y2pyblpHcG9QMjA2T3JmSW1vL3UzdlZlZFh5WkdsZ1hjMXBSS1ZT?= =?utf-8?B?OGU4SVo4ZDIvcDQrZ1lFUjZXaFUxekpnWHZHTDk3VlYydkV5ZUlBWEdSTVFq?= =?utf-8?B?UklQQ2h2QkU4QnprdUNlM1ozNk5YWDQxQmMvYzlVeExFWnpkd1VqeU5nV3Uz?= =?utf-8?B?L1hiVWlBeWFNd2tOS0lrU2tQVUNCckNPZ3M5QmkycktYYWwrVTF5QThDeFFo?= =?utf-8?B?cHFpYUJWQmpNaVVkd1c3S0ZxVjYzRzFkc3ZMRlFBTnRQampYc1ZadUtxOUFz?= =?utf-8?B?Qko0cnREK3ZiNWN2TlpqUE5aTmVOcW9WMEltcWZXK1JCQzVoZCtralZMUjls?= =?utf-8?B?NVUyRk1aNFF2WjAxK2Z1Z0NsMkNIQTlkeGxTb0NoWkM0YnNoS0ozQWxuY0R2?= =?utf-8?B?NGRCWEUwazFkVU42U1NIUHRkM3FRL05wL1dRZUUwTGt0QkdMOUt2UTNCcnUv?= =?utf-8?B?MzdOa1dFTFNiVGFQSmRnUzQvVzhOVC9ON0FrTk15dS96Qmg5TVJ3dldYY0xy?= =?utf-8?B?MXlRVVpPRHZSSW5JL09mbzIzQU1UMU15Mm81MWRhdTR1b2E0cVVkaFBVVUVl?= =?utf-8?B?aGtwRFdiVERxUTJyTTZsYmFnSkNJRlhDTE9hYTl3LzdqS0lQRTNNY2FlaWlZ?= =?utf-8?B?dzVzVHBaMG0zZFdDenNvaTBCYXp2bXZwUXpmaHJLU0xOdTNqUWwyUVp3SG5J?= =?utf-8?B?Z1NiU3o5emo4V1hhRnk4RDhGaVRzWlZWQ2prckRIcDVUbGhpYjBZVXZPc0l2?= =?utf-8?B?SDh3OXpoZ0R3Q20zNGZHMy9waTZZMW9TU0UvaGZQalo1M3NRMThVejFwWGJh?= =?utf-8?B?b29TakxwSTFwcDdqMkVLN2taUnBGL3F1QmlIUDFkOHMxbXNEWVdMNnU2Qnl0?= =?utf-8?B?eXRUb3lsK2FHMXZESDNlUHFhRUZYQ0xhVHBmeEhEL1lmYWIxc1JoRUQxYk5B?= =?utf-8?B?ZlNBNDF1am5PS1U5UUVDdHVSenhIeGhLVDVNMDdURGNneWo2bXdtWmdqczlN?= =?utf-8?B?eitya1VDSXBmeTh2ODRUR0QrcEdLeWZNTFYxVlpXVTYzWVFVbk1HeTh6T0o4?= =?utf-8?B?Y3lHYTVIL2EwRTVsQlhFNENna2lDcDZFTlE1ZWFsYUcxZTRPWHU5STF4Nk4z?= =?utf-8?B?azc1ejRzbzV4WTlsc3pEbzcySTVrdTdwWWNCeHRoODJQL3U3VEpJVzJwWEVG?= =?utf-8?B?c2dKaDRHQ2FNN0drb2FicnpPS0hkZG9PTXdBU3ZhZkNvWDNoYWt5RmJEQVp4?= =?utf-8?B?RUZmUUVPN2VhNUhiOW5aSWtxQ1V4YjU4QzdVS25oZ1ZuRnp3NFhVU0ovbk12?= =?utf-8?B?Q2pBKzJ2cnRDZXV6YWZpNHd4eWRqV20rZmxheFd1amNFR0NzZ2xhV3pOM2Np?= =?utf-8?B?ejFZb29SUFlHM1dUZG4yNzV5N3B6dlBZWWFDekVuR1hGMVRQVmVvN1pKM1Bz?= =?utf-8?B?Y2ZnMVAyVG9XRkRST29tQUxkRnNwOE1DeGFBL1NFSytsU2ZUUnlNYmJzOHRQ?= =?utf-8?B?a3V6U1lLcDNYMGx6c084cnVCMkcxcVg2TXBMeGh6akxaT2hWYm5lU2JoVEVh?= =?utf-8?B?dGhpUTAxMUZDeTA5REYrRVpMVmtyWFl0eGkrYTZSUUpIS1pKNDZ4RmJIcDhB?= =?utf-8?B?ajhsRG02Mzk1bzlMd3QvUDd1c0tHZDRzaUo0aVBkamlxRkN5aUNyK2lhTWNy?= =?utf-8?B?MGtPK2JkUCtLTHZ0N3NEWXZvYnY0a3JaNmQ5ejYrVlQvdlFzSWZ5R2tEZGhZ?= =?utf-8?Q?HCUg42JcSnfwYVW/kW5ya5qAj?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae98466e-dd48-42c4-5cb8-08dc54b38187 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2024 14:28:34.2527 (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: YGfP7xuDuWIaXmGph0sBUFGz1e/6W3cnXt5FUE6t+EWxKaDRda0lHqsTXg2kwDeS X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB5787 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 4/4/2024 2:26 PM, Konstantin Ananyev wrote: > > >>>> -----Original Message----- >>>> From: Stephen Hemminger >>>> Sent: Tuesday, January 9, 2024 11:07 PM >>>> To: Konstantin Ananyev >>>> Cc: dev@dpdk.org; arshdeep.kaur@intel.com; Gowda, Sandesh ; Reshma Pattan >>>> >>>> Subject: Re: Issues around packet capture when secondary process is doing rx/tx >>>> >>>> On Mon, 8 Jan 2024 15:13:25 +0000 >>>> Konstantin Ananyev wrote: >>>> >>>>>> I have been looking at a problem reported by Sandesh >>>>>> where packet capture does not work if rx/tx burst is done in secondary process. >>>>>> >>>>>> The root cause is that existing rx/tx callback model just doesn't work >>>>>> unless the process doing the rx/tx burst calls is the same one that >>>>>> registered the callbacks. >>>>>> >>>>>> An example sequence would be: >>>>>> 1. dumpcap (or pdump) as secondary tells pdump in primary to register callback >>>>>> 2. secondary process calls rx_burst. >>>>>> 3. rx_burst sees the callback but it has pointer pdump_rx which is not necessarily >>>>>> at same location in primary and secondary process. >>>>>> 4. indirect function call in secondary to bad location likely causes crash. >>>>> >>>>> As I remember, RX/TX callbacks were never intended to work over multiple processes. >>>>> Right now RX/TX callbacks are private for the process, different process simply should not >>>>> see/execute them. >>>>> I.E. it callbacks list is part of 'struct rte_eth_dev' itself, not the rte_eth_dev.data that is shared >>>>> between processes. >>>>> It should be normal, wehn for the same port/queue you will end-up with different list of callbacks >>>>> for different processes. >>>>> So, unless I am missing something, I don't see how we can end-up with 3) and 4) from above: >>>>> From my understanding secondary process will never see/call primary's callbacks. >>>>> >>>>> About pdump itself, it was a while when I looked at it last time, but as I remember to start it to work, >>>>> server process has to call rte_pdump_init() which in terns register PDUMP_MP handler. >>>>> I suppose for the secondary process to act as a 'pdump server' it needs to call rte_pdump_init() itself, >>>>> though I am not sure such option is supported right now. >>>>> >>>> >>>> Did some more tests with modified testpmd, and reached some conclusions: >>>> >>>> The logical interface would be to allow rte_pdump_init() to be called by >>>> the process that would be using rx/tx burst API's. >>>> >>>> This doesn't work as it should because the multi-process socket API >>>> assumes that the it only runs the server in primary. The secondary >>>> can start its own MP thread, but it won't work: >>>> >>>> Primary EAL: Multi-process socket /var/run/dpdk/rte/mp_socket >>>> Secondary: EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_6057_1ccd4157fd5 >>>> >>>> The problem is when client (pdump or dumpcap) tries to run, it uses the mp_socket >>>> in the primary which causes: EAL: Cannot find action: mp_pdump >>>> >>>> Looks like the whole MP socket mechanism is just not up to this. >>>> >>>> Maybe pdump needs to have its own socket and control thread? >>>> Or MP socket needs to have some multicast fanout to all secondaries? >>> >>> Might be we can do something simpler: pass to pdump_enable(), where we want to enable it: >>> on primary (remote_ process or secondary (local) process? >>> And then for primary send a message over MP socket (as we doing now), and for secondary (itself) >>> just do actual pdump enablement on it's own (install callbacks, etc.). >>> Yes, in that way, one secondary would not be able to enable/idable pdump on another secondary, >>> only on itself, but might be it is not needed? >>> >>> >> >> How secondary, lets say testpmd secondary, install callbacks without >> getting 'mp' & 'ring' info from pdump secondary process? > > Please see my comment above (I copied it here too): >> Yes, in that way, one secondary would not be able to enable/disable pdump on another secondary, only on itself, but might be it is not needed? > I saw it Konstantin, but it wasn't clear to me what you are suggesting, that is why I am asking more. Do you suggest when testpmd run as secondary process and doing forwarding, it should do the tasks of pdump itself and we don't use pdump at all?