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 75B2E43DEB; Wed, 3 Apr 2024 13:42:32 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F318C402CE; Wed, 3 Apr 2024 13:42:31 +0200 (CEST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2116.outbound.protection.outlook.com [40.107.94.116]) by mails.dpdk.org (Postfix) with ESMTP id 4E46F4025C for ; Wed, 3 Apr 2024 13:42:30 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kOiDdCRZ20BKzB9sfNGmDO1M5EtQmMAe3FAlpSnZb78iKALOD/Vjhm9Eh+u4Tua00I3rJjXl80Qcqu2nvF+CMupYR9SYlFyE/9KhekYO+bAfJ5tUiyC16WTJ2V0WjLc3zbGPe6Fplmdw4p6uHQEWL9w44dwOmsLdO3OoEt34OttfJncHNAbKbHAWcixSasEvfD42s4m8n0New+LZsON/Cp7LPpI3XHpSUtDJUN7lpgwbJ02alPhrV3GER0rBrNZ3Yov4XTW+uyx/jwrRVX3V9LB9i1LR7qKhBhsFrTilJrIvWFEaQtsmz7jyNwFWbvjp7ViO+0M90ALY4sTacsb2Lg== 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=aGhkTf0DXmJLdG7FL5mLj9PDA2zLXvI83BWi9oiv/30=; b=gWb9B2rrGvlbWJnr6Ae0EvyfL3DuZZPkzGyqvaC6lC3Fr26ld/TBhxwIDH2gGTndVclkliHJWtPmXbkd4aQeufCxCScRTiG4tqkSvIpTIlk8zxefvvL74M3qOV0bsmfLnhqDUs8niscR8/TQiwzdr7V+bt9vlytTx117El2OK8cuxyOgNST6JJ5ZFuoSbCfVr/auYU/zV8kClSmkm88kMH1YHJWUcvm0Dm7yeH5WXBC5EsOyzlW1CORHvfoXgtkP6uIeZezozKxs9+dzbsSx6AXjVRVf7eN78Byr1Yboju9zIk+gc4rmTY6PKxE7aYmxWPRdE5drrpjyp+nDZAHaeA== 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=aGhkTf0DXmJLdG7FL5mLj9PDA2zLXvI83BWi9oiv/30=; b=dV17T5QgzW81ApOtfDgdgtiwKfdPd6sF3ee4AuOmSmneE8l80be31hXXoctZOddDxov95wvr2+4/jTVT38z7dSbhJRgJU8mWn6hmmedj/OUCCx1zlrmSfyNtLhX0x0DfCXSaEYH62iibE9x/f8E33zKDaavSRpm2NIUAZzw9//M= Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by MN2PR12MB4272.namprd12.prod.outlook.com (2603:10b6:208:1de::14) 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 11:42:28 +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 11:42:28 +0000 Message-ID: Date: Wed, 3 Apr 2024 12:42:13 +0100 User-Agent: Mozilla Thunderbird Subject: Re: Issues around packet capture when secondary process is doing rx/tx To: Konstantin Ananyev , Stephen Hemminger , "dev@dpdk.org" Cc: "arshdeep.kaur@intel.com" , "Gowda, Sandesh" , Reshma Pattan References: <20240107175900.1276c0a5@hermes.local> <5c28d2a26f5142c3a509cc8bda2fca75@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: <5c28d2a26f5142c3a509cc8bda2fca75@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0272.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:195::7) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|MN2PR12MB4272:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9M5/MEKKR+oIMKGj48+KkRpqTkdKIEVjHgyE97CNzqPyP2DTNjHVl3dRv3tnbBIB3KG43F8L+mvGBSrkXCg8dPuBhey9nsmn8E0d9GYd7YhZR+fwSW/vghpI5w4KBn+YhZPkOHdS93JMno55sSjYhUxINFZrqJpyt0wHG2rQOY1TFXawwtffFd9CGpsti/zNR4fPgVJp8LN6SDNTDLATVSgwksK3MiX+v87aeu5CL8xmbDWpplNPEiXkPLrF/4RrlYi1QFlVJPGnns43A6WaYUjY1H48GxqPYBtZnWJA27FSfkEL43qsB4XT0yCnzZW1l71+f+wgrQ8vGfiRoE9X990iGSBFzaioJ9g2P2hyoKczku1nbW0uj5BUJ84licRvs7EiMX9KqUqD3p9YvMaseG0ZRFjudLMQ4dWzP8dISW50SQyY7424KR7wjn4sGLykvoF7L74HIyywNr4s8S084JIb7S2Vuftqt6cr40UGOnYgMv8umUeDB1x4zHDp11MhIRiCOmGsUtI+JW17P3Yn520gf6v699gb+pvL5jj1zHoxchoT4FMIRfhtAkiBbYSJ83MxSqalnmRwlGUZ+7mJE8jLwiOSVvn/3g3nSxJE53jSromKLABi9zMeSzrPHpICdKkhwzxPtJd+WK0Nw7YWNzShbvAERuhusk0LMTS2VB8= 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?SDdsK3Ywc2VoaEpFOUVlTm4yT1JMaGxwai9SRUljeDZYTnR5M0JYQmx6Zi9L?= =?utf-8?B?VjJWRUpGYlViSlFlNWpEUElMZ3RtUTdFQXQrU2thdjF5bG5NVFE5WEc2ZURp?= =?utf-8?B?ZXBNUzdPbWk3Ty9VWFREalJjRTkrOTBXa3I4R3d0TjZxVTEzUTRpTE5oUUJK?= =?utf-8?B?K0ZvQWRMMXI1MjQzRjRqQW5rV01UR0Y2bVFHWnhieEdVMnZ5b3FIVDBWZlFH?= =?utf-8?B?d2dab05rV2V0Ujhjd1NYVVRVVDRvQmQwUDI5Rm9kT2ltTFlBUG1PMGMvTUYx?= =?utf-8?B?Ui9SQ253MVBteEJ1OGlKWC9IdHliN2VsT1JBaitCK09SYkdIajM1cC9lTjRC?= =?utf-8?B?RXZtUEZ4SnUrY1l6dE1TUENtS1JDS3QyalFJZ3pVcVdUR1JwcEVHVWV4a00v?= =?utf-8?B?bWs3TkN5aGh2NG5aaFZPcWljMVQreHBKTHE0QnNwSklJNC9zYS9hKzZYM1Y2?= =?utf-8?B?TXF1eU13WGVYWXlBMk9VeUt2VUx0UGFhanBxa1JYOURJaFhqTkpCRnozZnRL?= =?utf-8?B?TGxVc0JWVG1ZNnFhdldGSXU4ZVk4YVBkYmpYNHVvQ3Y5STdNSDVmZUJpKzFV?= =?utf-8?B?L2V5QjRPbnRwTmNYaE5KV0h6NTRMaTNTbGkvdjFveEhsb0pGdmcrbkdvR3RP?= =?utf-8?B?VlJlZlFlazZ2SVNsbTZjcVNadkxhdThxUThSM2ljWU9kMDdQdTEydlg2Rm1T?= =?utf-8?B?THM1SEExQ2gvbnNNN25NRWRXYnNvaTBkOHlUUlBreTUvRzJwYUJaY21rN3l3?= =?utf-8?B?UmZUcmc5aE1KUTFiWHIrVW9JZVh6ZHEwR1J2ekFFZFVjWmF2aFoyREpLVGpR?= =?utf-8?B?RkFKM0plQUFPblFmOVh5YThkeWhldFd5T3dwNTBYbkp2WUFaeWdIWE5QdG1F?= =?utf-8?B?aXlsNENRNzhuK1VXY0JXYUdVZU8rdUo3Zm8wSy9EaHdLR1llWlBlZzcxNzNI?= =?utf-8?B?MjRDNGprRWptZWYrWmlkek5lbGlGV1RPNGdaRFQzekhiUFBYcjcveld0RnNy?= =?utf-8?B?NGl3aFVUK3NNMTA3bEo0cm5yTkJLTlFRalYyY0xDQ2EyNGFHb3FuY1lPVjZu?= =?utf-8?B?VzRyMGw4YUx1M3R3NXdickc0MzdQODI3YmlYOC9SSGRYL2M5MGkxaytXSVFL?= =?utf-8?B?WEdpa1lNZ1JZY3R4TmRqNEpOUnF1TkliUEEveVp1VmFja3RtTW5MajhuRFRz?= =?utf-8?B?dlltVXhHb1ZmSmZYak1hSWduUzZlMjJtUmNqSEpCemZuY0tOZ05GYy92ckVi?= =?utf-8?B?S0xRUDF6aktPTUlIbjc0R2pWVWMwZ2tkcVhKalRxbk9INXRWVHlzUnpDYVJP?= =?utf-8?B?bk5CamhoVklvQU5IZS90cFZaZlJEOHRITnZmT2JKS2drUDlDcWZqMDRCWkh3?= =?utf-8?B?c0MzZ2Y2VkJBK0w1SHUwL3N5UCtNdEQxWCtFUUd5ckhvc3E5dUlTeVYwMGp3?= =?utf-8?B?N3kxRy9aV1N2bHNwdHZsU0EwaVljVDhtWWFvRk54NytaajhOMkE0K08zc2Y0?= =?utf-8?B?YVZ3RTkwN3ExZC9sOHROUk1GV3V3RDVLRC81MGEzYWNmMWxvNDZjOWVTeFZH?= =?utf-8?B?ZkdTbE1oWENySzJYMUtRU2haWktPLy9HT1BBTFp6UjRtUXV5VmJoNlJGSWp4?= =?utf-8?B?UDRTQ3NLb293eEoxTnV3OXNieWZZc3hnODdmbnNNd1FINTdpdDNTejBKb2Nv?= =?utf-8?B?MzZ2VUNKSUw1cWpwOVk4dG4xUWxjdUMvZWRSa2xnbmN0cktsdnhDTmFkVGxL?= =?utf-8?B?dXVDWU9mTmlheE04K3JTYlBMejJoU0lER2dzaUxOK2g4REdYbzhYZFBzcmtT?= =?utf-8?B?bGtORHZhRlI1RElpSHhWUHZ2ck9mM3M4dkdTOWlaOHFKWlpBMjFkU3VDZVUy?= =?utf-8?B?cDkrNjM0ZFZKZE5EWVR1czBNS2F4ak1YYTFTVktqS3RzL0NQL3FlelFTTVV4?= =?utf-8?B?ZDFPcjJzL2FNTWJ4ejhSa1RvYy9jcEdLbllwSm1PN3FlenFRaWZ4R1V2MWFN?= =?utf-8?B?MFBadjhGeUQ2d3RCbnFzSjR6Wm5YV3FSeTV0c3R4R1JpU0JrVGt4VDhzbzhT?= =?utf-8?B?NzBXTHVXUFJlZ2RXYzFHcmI1elpmRU43S3JDZU5Kd1UvcTA5NkhneEVlaFl4?= =?utf-8?Q?KB5Bsv0txzBzanmc46UQvGR/8?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0cd9e39d-8513-44df-962f-08dc53d32315 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2024 11:42:28.0337 (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: mw0ZZpHoUkpLcDYcoMRagbxP9lrC1LYhmDcPMTwEhM5vzCwCQgWk9qtjHR8xauHl X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4272 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/8/2024 3:13 PM, 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. > Ack. There should be another reason for crash. > 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. > Currently testpmd calls 'rte_pdump_init()', and both primary testpmd and secondary testpmd process calls this API and both register PDUMP_MP handler, I think this is OK. When pdump secondary process sends MP message, both primary testpmd and secondary testpmd process should register callbacks with provided ring and mempool information. I don't know if both primary and secondary process callbacks running simultaneously causing this problem, otherwise I expect it to work. >> >> Some possible workarounds. >> 1. Keep callback list per-process: messy, but won't crash. Capture won't work >> without other changes. In this primary would register callback, but secondaries >> would not use them in rx/tx burst. >> >> 2. Replace use of rx/tx callback in pdump with change to rte_ethdev to have >> a capture flag. (i.e. don't use indirection). Likely ABI problems. >> Basically, ignore the rx/tx callback mechanism. This is my preferred >> solution. > > It is not only the capture flag, it is also what to do with the captured packets > (copy? If yes, then where to? examine? drop?, do something else?). > It is probably not the best choice to add all these things into ethdev API. > >> 3. Some fix up mechanism (in EAL mp support?) to have each process fixup >> its callback mechanism. > > Probably the easiest way to fix that - pass to rte_pdump_enable() extra information > that would allow it to distinguish on what exact process (local, remote) > we want to enable pdump functionality. Then it could act accordingly. > >> >> 4. Do something in pdump_init to register the callback in same process context >> (probably need callbacks to be per-process). Would mean callback is always >> on independent of capture being enabled. >> >> 5. Get rid of indirect function call pointer, and replace it by index into >> a static table of callback functions. Every process would have same code >> (in this case pdump_rx) but at different address. Requires all callbacks >> to be statically defined at build time. > > Doesn't look like a good approach - it will break many things. > >> The existing rx/tx callback is not safe id rx/tx burst is called from different process >> than where callback is registered. > >