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 EE27943DEC; Wed, 3 Apr 2024 14:20:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 77E0B402CE; Wed, 3 Apr 2024 14:20:12 +0200 (CEST) Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam02on2101.outbound.protection.outlook.com [40.107.95.101]) by mails.dpdk.org (Postfix) with ESMTP id 2550D4025C for ; Wed, 3 Apr 2024 14:20:11 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aCREUV7Q+DtKendjp4PrbtgKXqJtGUyFk5WMkLzMIV11UgRWLWVTmfJcSuoFD3g9aH0wd07UZHMt9zkgXaAc+QTJgK3kyWF1rZQ7u76EOSf9FMo1KsccogSA7TlpTJ2dWHtZlD5Fz68NQ6rRIVMPgKNe/R5C90LjEISg83AK4yNsGJdUxt6XcsT8ygVJrHZrqxxPvR2EjP7/SXlN8Agt66FFWqtHCrr1YGlYWRpyTZphzvEecZJ4pIhPpPB0+nvlfWkg1tSONK+YiFxQQOqE1jxg/4qgASmFOOsrBzqqdExeGmP51YiK9Q0JHCteNl9N/RtT1RYT2Xwq05B+zovO+w== 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=F++LQA03dnQCmFyhe5snbrIxTIZ2SzXzGaYsvPsu3Jo=; b=DcSbxjxdXRw94FI/IiVYinZEewq0Pf6C37DL9aDrVjwdA7be/9RntO9CnFtQjkJYj5IFB+Polg3VEQ7i74RxxNSXa51qM27qbnfy9HHXBJJywLZvEQ0C4wBQ9wvCQ5ynIsAPUevqL/8TvnN0vJaVujyrbELp1JBTPc7W9ZFTJliIXFj8lhFz4pL00D0Rx92Woi0mTRD0tXxyfIYkd/R13AYqwwCpW/dYyMaJ43aBZexfxmZF9sZPIzta86h5MgZUyzpCjLwRmOY6KHioRWj6Y6GmKH+24pIoiA0twjc9deXLOuvBim+KtRhzKvkMveIAENcBF2zovgDrRw+AYiTEkQ== 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=F++LQA03dnQCmFyhe5snbrIxTIZ2SzXzGaYsvPsu3Jo=; b=y/BGQ1eYBiDsakYcfOKWJTPYYnK+M1E5mM4IgUMa4Triu9jramkVliAwNfgSvBKIK4OgvpfLzS/MmMXvddrl/L5H5R2wER67Zx784t0j9j1A8jK7vavX3BOJfxnzeARc9p1+Q3Xyn4B/YDdthjfSGMmGAUf9Qtt0dl25ORQzACA= Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by SN7PR12MB6672.namprd12.prod.outlook.com (2603:10b6:806:26c::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.46; Wed, 3 Apr 2024 12:20:08 +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; Wed, 3 Apr 2024 12:20:08 +0000 Message-ID: <6303f2bf-fc5c-46dd-bcac-f79c0c824a02@amd.com> Date: Wed, 3 Apr 2024 13:20:03 +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> 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: <59dfbb6360104c348b4eb3dc767b0233@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO6P265CA0026.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2ff::16) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|SN7PR12MB6672:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PE5fOD/DUsXJcjxPECP1nTfTZmR14bipI849oWdpvYt/78n80gpdNinT977xl5+vwtry2gdnqbfSDOefynrSmCV+zPXzcIIsEgL5DFoDkTVLmHqUSFulhA1O44U7mQ6MiJtZWGQOn5eGwAaiColRJHk3hPSwaiy6M43IAxg8cxAbMYCM/qkus1qx9ji/0NGR4MPzj5LJNd5PJBluaAEwCb1gZZz84zdrc0XpsZG/hNwWeDkUlnTCOYPjNDpBqG2vhoKSZsfIFlhbsA7p7mNaDMPmQ7+4GaMyTRpCbsNrcpuxClBekx4Y7c/qflxXLB3TM6lhCQ6sF5TNNK4Pge7PjcqgBDUQyEMkMlzRyWcBjEWkGKbmYu/9LIemI8C9KAIjONct+NF7lwNsLbFUFZGfXB5eHASwvPDJjrnS4jTP0BWmRa3U/d/U8dmu09nCPrIY0j3/p8aClWsqeYpS/1ypBi1dFGzfC1Rm2VhNGRRqE4szu0lRCxJydG6T53lXp0UZoqKr42R0XO7OPUaydAAkhcPJY1qk0/mKWb6QUqm04iAn9NQv4yHfg8kiZatSa5EEiy12bXl5xznfZLRm2Y94rtaIypPBCcSplJlQVLH1KEP4/A5g+GHD2Vq4ys5IydGzx9MOMiHfUM4eA+g+Mhgoz8hsAdFt0uquo/RY2hO4MAg= 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)(1800799015)(366007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bFZyYlYxZzJjRC9XdXNIUGh4ZzRjVHRWWTc2cUhydFZ5b1JuYTc5YTFVTzJF?= =?utf-8?B?a1hxQ01BblBYN2VUSkZOT2NpVkNqTUhDV2lLRjVVd1RpaUdzTWh1NCtmajBi?= =?utf-8?B?RU5ZcUdMaTB2SVI1OEVlalZZKzRkbFZJZWJ2VTh0Skk0d0hIUUFvLyt4Wndh?= =?utf-8?B?ZE4wb2k2d0FMNTVnc3RyVzEwZ095VHZDS3lYdVB5RnpiWko4bXFLaWJINktR?= =?utf-8?B?L1ZZcHFqK3dBMXhKRmwvUTJNSUlDMzFwSmhWSFNiWHhJRXdjR1VYTlE5OENI?= =?utf-8?B?VndRT0xvaDB4RzJqMkpDemUyTGJ4NGpYeGEvTW1jUC81TzQvSlR2QWpnR0dn?= =?utf-8?B?VVh4RmE2SFJZTDRMNWdLWHh6UjdZVDdnM2NhSGNsaGUvbks3OG43R08wNUZT?= =?utf-8?B?eTlqVHNrV1dMVHgrbFlqN053NnpoU2RkZ2QxYnRVb3ROSnozV21JMVRYcnA0?= =?utf-8?B?R2FTc0oxYkFhd2xxcnB3bkRGekNWS3NXUWh1d0d3bWdNNUlQTWFXN09sUTk0?= =?utf-8?B?QTBRam5DeXRTTDl4dVNZYXdFNmFNT0pMTFNQQjc0dW5NWXN0ZExqUlg0Skpa?= =?utf-8?B?M3J1eXBDbDVUVEMwUTNzanpaVmFObXhNYm81UmFMdjdvb1U1RU54K2Q0UkxO?= =?utf-8?B?MTJBVHB5QW9mdEt5Z3FXblJTY2dGMjQ4cWVMeEp1Vi8rdzU4a0huWThnc3FI?= =?utf-8?B?MldienhnVVF5dlp0aWlFaTM0dUNjUnVmaFpROFRSZ3BzelpjUkNDcmpqYWVQ?= =?utf-8?B?R0JBTWsxQTNucXlNbmFNNnVBUEZHQy9vcHQ0Z2xCWHpsYVRmbmQrU2w3T0Z0?= =?utf-8?B?ODBmVVhPTmJGcWhkRy9ONjlrWCt4QWJYT1MwYnJLbXBlcGNMZ01MK2hLL1Fy?= =?utf-8?B?aG9qbjNhWTd4TkJuZm81ckw3dkNkMmkzOVY1SHpibUlKOW1VZm9sMmxqc1RH?= =?utf-8?B?MzQ4N2JSdkRwSmo5WnMxSnhiam00Y0I0eDhTMmZ0b2U4S0pNTFI5eTdMZmUv?= =?utf-8?B?YURaUll5elpic1RPSDJxWm1TZE03NFhFdmR4NzB1SEpTSmtFLzRsUHRxL0JW?= =?utf-8?B?bThTMWZtYkhUQmZWQkIzdk5YS3gxVVowWmt1bElGT0xjNE4xV0tROFpibjRl?= =?utf-8?B?OG9UNlJsbXJrb2U1Ryt2OVkrWUFjR0VKekRxUmVOdXJPekNuMm5QMlRSQkIv?= =?utf-8?B?ZzN6M2VFbzJ6ekozcStncHd5UlBOQ1Z4NUNPUHJ1ZThITDJhWVFqZjlxWW5p?= =?utf-8?B?aDdnamZVaTgxSDhVRmg5ckNJZEpsVVlLL29sYkJKUGZDalVtekF5NG9wUGt6?= =?utf-8?B?akprZFVQUy9YRkNLa09XZ0NtTFhwRlg2TnBOa2FSOVY2WTl5U3FYNUV3cmhW?= =?utf-8?B?akFNa1JsMDZjcWpidmtrTFljTXNBWDMxRTN0YVdiK2VXSktheTVkTWV6b0pJ?= =?utf-8?B?V3hGYkVHQ05DNGwzdFB0KytFOWEyUnpJVXJhNXovRUtVWTAvcmo0Lzgrc2JI?= =?utf-8?B?eXkydDJWQVNjSFEzKy9yM3Y3MVNXUVBIY29iWU5CU2RPSkdZaDZkTG15T2E4?= =?utf-8?B?dGwxcmN1Tmt4cHRjUDVqTDErck5VZ2xSME5mMlBIeXJOYU9CZ3FpUUt6WktB?= =?utf-8?B?cmZLK2hicGU4ZjZ6WXgrczUzSTBvOHlKbVBGY0Qxb1czTVB2TVNPV21xUCtZ?= =?utf-8?B?RHVRWlJKd2UvMlpuL3U4RjZQS29NN0lpa2pwM1ZGR2pzSC9iUm0wNysxMzBw?= =?utf-8?B?SmhjSkt6aTVJR1lXQ2pMOHplaWNUZzRMUXd2VmN3RVpyRFZKOXRvTWxHM0d4?= =?utf-8?B?ZjNPQmcrMFZwRVE0OUkwSzlDa3Z4TFdVNXJBRUU5RWIxWWdTRE5oTHYzYTY2?= =?utf-8?B?bXQwK05ZanZjV0RoU3NTZzYrckJid0xwMkExVVBNK3NOV2ZzTlZ0R3hiN01E?= =?utf-8?B?Sld6TTRoaGF5TlZldzdFRlRMN1M5YUhiRDVYWm9Vd0prN25LNzRnY25VRy9J?= =?utf-8?B?c20rNlc3S052MFIvNWZQMmZFcDBWYlFVa1lQcEFGdXprdnpuYzNwOTMzSG9r?= =?utf-8?B?eGMzQ28xUEIvTGlCdkVPZ0ZYQjVBeUpqbzRQT1U2QWk0QmVPcklLNXBwRG1o?= =?utf-8?Q?cyGrYgB0K5IQDdLALU846z2w3?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18f02113-3d8d-4b9c-19c7-08dc53d866f0 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2024 12:20:08.6969 (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: /nh7lwcGvdPuKxPDtv5ykSNhuaw9G6HUktTmx3rUjEHABB1DKD2SK/Ush+pCGTlm X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB6672 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 1/10/2024 8:11 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?