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 5B74743D7A; Fri, 29 Mar 2024 12:24:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D32734014F; Fri, 29 Mar 2024 12:24:55 +0100 (CET) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2115.outbound.protection.outlook.com [40.107.93.115]) by mails.dpdk.org (Postfix) with ESMTP id EE80340042; Fri, 29 Mar 2024 12:24:53 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YvN/bHz15ytCJabOTtc/89PfdmU+vlul4b80TUAvIe0U+keG1cq+JVZDsun26qTlSNRtM7bAFlI2WgRehSaJfTlnQWIZCs4Zb7aeMK3VLdDDns5UgQfmV97X6inIuFX4xZceGqIzd/lUHm7szo9aCwjCQegGyp1/izJCMzVCBw+RGI+/gTCWxlyIZwV6uyZiIeTXWPb4jDL8NuZZlwAGYarImmTCs6R+/KRHyt638NMW9rXcDppncG3PcaXCk8ZVFSzq0KY6jiksP1cMZPetrthrJhvbbngkjuTUIFlglWmzxiQJtzS0EPjXiqlHJrWONNAaW2OcDdTbEsagxj+wUQ== 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=F65ATuyLdNq+GBvhQ8FCwkQogx+2Bf7JoLa3noXfNJQ=; b=DJCr1HZmJ79yThOOO4JqSNgDAaWKVN9ZPcH5JyaBcca3o0vq8pTtiM9+V8YRl3KQHl1ZqDIPSU+Jr03qjPRpuNWo5tVxS5lDdTWeLBnuoMknm2J8hWaeRtXFWS6aWLMLmP0BoO6feVO1bpQrrpEvYTvq6WgP6oRv48xyZhKz034ejVhH9cEePIhRAH/JMxu7+NvpMWC2eB63j4YJ06/p0eBaKYKvy2MohdpvspkBZIdYo2hvc2Xa25InlDWTeR0MB8GxQMjzZyQVJms2czqSz2KB19lL+FAvhjcVRBugdtFG4J2KIoP9Kc1Yaa4jxbKbQqMKw1ayrorZxOvWBsM1MA== 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=F65ATuyLdNq+GBvhQ8FCwkQogx+2Bf7JoLa3noXfNJQ=; b=UcsvQ4BMASHYCiMasGSKqB5mvB/KQi0ZdJS2zXYmcIUOV1vnxCVt4BhQBZOdGXMlpSHmPo+ydwh49lFHbT/aXxboUxTzt4tqBCRz//j+W+uU8hPqnePLalMAHLJNYZBKzIcUr0cchgyIgeZOmEW+Rlq07JK1fdk4+EUW4rlZkVY= Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by CY8PR12MB8266.namprd12.prod.outlook.com (2603:10b6:930:79::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.40; Fri, 29 Mar 2024 11:24:51 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::282f:29d3:cac1:cde3]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::282f:29d3:cac1:cde3%6]) with mapi id 15.20.7409.039; Fri, 29 Mar 2024 11:24:51 +0000 Message-ID: <4f8b1bb9-0e9f-402e-849b-c73bce0cdba7@amd.com> Date: Fri, 29 Mar 2024 11:24:46 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v16 1/8] net/ntnic: initial commit which adds register defines To: Christian Koue Muf , Thomas Monjalon , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Mykola Kostenok Cc: "dev@dpdk.org" , "andrew.rybchenko@oktetlabs.ru" , "techboard@dpdk.org" References: <20230816132552.2483752-1-mko-plv@napatech.com> <4ba561dd-0fda-4132-a909-bbbb9da80919@amd.com> <4244980.IobQ9Gjlxr@thomas> 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0242.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a7::13) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|CY8PR12MB8266:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uzofs845PUHsSivqyuIKIuMu0gmhuFKYEdzHue1YTNgjC/pXSuyaHH7N5Jo0lpLqJCNbwauJjNRNQ6CnwEnCvRTx9nbRTbTvQqk8mXF6CaAZ4k8XTYDUC0+fcO/jPOafLhJhHiZVanfBJnHUoONejhJJ2TNLpPbVrsWLazSa/95DGYHFRizeJLl7rWjR4XbN3UiG67Mi43VyKHPyCy+6D8FvxPAYRsQagYaBURp0hRogb8QItq3MJUQzrfDJTRd/sbC8rguhLC8B9/Uh8TZIjoB1Gu/YMj9+e04S3seR+hsj6r5FRw0kriAuBwx0HSiumB5XoA++rDJjIpU3vBmt1MUoqoQh0JVlJWsi2KnH3Tl0XmjNviscfdG1P3XX9GANhjNTrWK+dbAIRYoiT9gdhDjx5zjHNDkP+1EDEseSRlGOOM9H9Dyv4u/V+gcxdr9Nf123qvKIIlu2tCk5disQdO/0wXlnMR6A1/Tpw1VOCwDAMbvPAtR1YclQR9b3wtbisnyGL/FTdgB/+CNzdKlGwRhZ3GM/GLgP7Trb3yCN69Fcj6L9cwm7eCqvYuMXplPbc2C/psNQXENt9Z3zy8Pkib4/pI8Yqns9AAn/1G4h9mU= 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?TjB1NkREc0ZLRXozYTVGWU1sVEV2eU0wYVJNbG1WTGNOV1VhV05ydW9wQzhw?= =?utf-8?B?WVhyUXVtU3dWRHJwNFNURHRUdTRBMGtwM1dyR3Z0bkdIaFZJSkZaSkdqNEZ3?= =?utf-8?B?bXJuQVlkYi9jQjhzMDlvc1BwUVF5RG41R1F6eThqRk9mSlFJa2F3a0FTN2RY?= =?utf-8?B?dDdvTHlwbEZqbjhrNFpmVjJmSGx1Q2lwUWdJSTFKNTJVYmp1SnQ0S3BCei9H?= =?utf-8?B?Wlh3K2k0NjBEamkrb0dzcWpWOTJLSHRLdjZSZCt6ckczSnFTVXY0VitISFdn?= =?utf-8?B?eEhVSDE1Y0gvVkkrV3Q2TjJFRDFSSWNmZWpJQTEwWFlrRUZ0NW9MQU5zeW84?= =?utf-8?B?dVlRMkpxdEpVYk50T0RObWRNbjBCc3YrTzBwMFRVaG9BLzdvWGxSUTZ5c1Vj?= =?utf-8?B?SWx0OG9LZDdkSW55NnloWmY3dHZJM2ladGVEU29jbjNmbDQrMWtpSFYzL1kx?= =?utf-8?B?REIrcGhHQS81dXNzOTgreU16NlpNRGh6cWprN3JVS0xhN2gxakVieTZXZTQ0?= =?utf-8?B?ek15dGpLbko3YlRGYUxvMWpUSFFGeHRFR0Y1VG00d1N4WHZSQkYxSHZNTG5G?= =?utf-8?B?NTBqOTZHOVRYdUUvZDE2dDFVdFVUQjBkSXJQdTdzWXJMMituMDlBTDVtWHVk?= =?utf-8?B?dk1PR3NiSU12Z3I5S2gzRm44cFJTVlpQeUQxWG1iYXE2T3hIbWM4dWg4RkRQ?= =?utf-8?B?ZXZwWlozTG56VGFoMy9nZkNyU3oyL0NxMGwzSDR0R0hpSy80SktOS1BTc3Bv?= =?utf-8?B?ejhMTHdDWnJNWllnektzWGZtaTAyY1psbkVqdUdDZHJFMXpmb08zNlJjVXZ1?= =?utf-8?B?Sm9vNlgwZTU3M280cDg2Qkd6YXdaZ1NyNSt0MDdlcjRZblNJWmNGWUYvcElw?= =?utf-8?B?QTN4Y2ExKzl5dTNHeW5DNmFtbGJxUTFidy9EY05Wb2M3eHF4YkEwTTY2SURZ?= =?utf-8?B?bHgybVd6eFVlZUdqWUtnSmdlei9FRGxkTmw0dmhWNFdOdkxhZHdVbmVoTTI2?= =?utf-8?B?OWtNYjJ1ekhYMjAwZTJEdWpKQlp5M3RBaFQ2R1Q5Smx1QTRxVnExbDdjZlp1?= =?utf-8?B?M0l3bFBHSGZVWkQ1cmNYeURWbFdzUncvN0czNVkvNnpTTmVFVEFiQ3NpeGll?= =?utf-8?B?am9nUjErWHNsdDducmxYY0lvMVZGS3JvaUg2VEU4ZHN0UTF0OVRhaVFYbjdO?= =?utf-8?B?YW5vOVU1aGxNMUdibUMycCt5ZEdpQXU0R1h2YlA0OWU2ZzdzQVN5WE5DTmZH?= =?utf-8?B?RldwcVNKWlRadk5yeFNkaklLdkdTYlVhMTNUVnFlTS9VN1M4amFhVDFlYzdN?= =?utf-8?B?QnVZWlkzRjdhNmd2MTc1R1BkLzhnYTgyRjNYRDJKbHg0dVE1RUhWOUN3ZWRE?= =?utf-8?B?U2FucFdTQzJ3a21pa0svdkx5emE5VEwwemR0ZHhiaXE3bjV1MXpucDJoRVNU?= =?utf-8?B?bG1TN0JCMm9rRzA5Unk5Q1ZWSDUwcU03RGpVbWcwd1lseWlYMEZXMXZweE5S?= =?utf-8?B?NGs1M3BBNklnK1lCSGtSK3Frc2ROY3FhT21HQnNDczFqTHJkdGV4NEtic2dF?= =?utf-8?B?Z2JoMU5pTWpMWFJMMUU4cHhuWVlwTDVURmdtS1ZCa01mbTRGdlFvZUdqdVJI?= =?utf-8?B?amxGV2cwRk5HelNPTnhkcTlyN1doQ0cxSE9nT2s0NXdSQ0RxNnYrbnhDRUk5?= =?utf-8?B?MDJSTlk3alRVdEpyM052SWZtcnF4V1dlaGg0UDd1OFh6QVFCOThKYjBBODFq?= =?utf-8?B?WnVBZ0VXdVdkK1Y0VlVYMkdmK0RUN25LWUVpVXlheE9WQlQ4VzdhYy9sRFg5?= =?utf-8?B?UVNjbHBvdEZmakYzci9XRFNEaXE2V00raEdPSkRPMHZrck9rWWtUZnM5dWtj?= =?utf-8?B?eFZkMWE1NXpDeUFyZStGRnhnVFo2M2gzenpYbXJvMGJkdVE2cnpwbXhrVkt1?= =?utf-8?B?aVM3QVEvNzJzOGIrYU44Z3NQeXV5bFlvSSt0SFRoOGhHM1I0NExISTNqeW5l?= =?utf-8?B?ZU5neHJYWk0yUE5oK3luenBVSWw2K3NmNE43cHgyVlkwRlZmZnNzWVB2ZE1J?= =?utf-8?B?ZEpnZXY5R2czNXdFTjhlcmZpeFlLOVlhUEM5ZFdoSmlWWUZhM1pYellCekp2?= =?utf-8?Q?xOJeGhDr6AMdj4JR1BblVeWi6?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2181a54-ab6f-423e-64c0-08dc4fe2d9a1 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Mar 2024 11:24:51.5430 (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: tPO/rWrzjz+mlAoMgcrfdcXh+9cjp20+CpoVms9lIKXq1BGL0+NBestS3Z6b2gzN X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR12MB8266 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 10/9/2023 8:57 AM, Christian Koue Muf wrote: > On 9/29/2023 12:24 PM, Thomas Monjalon wrote: >> 29/09/2023 11:46, Ferruh Yigit: >>> On 9/29/2023 10:21 AM, Christian Koue Muf wrote: >>>> On 9/21/2023 4:05 PM, Ferruh Yigit wrote: >>>>> On 9/20/2023 2:17 PM, Thomas Monjalon wrote: >>>>>> Hello, >>>>>> >>>>>> 19/09/2023 11:06, Christian Koue Muf: >>>>>>> On 9/18/23 10:34 AM, Ferruh Yigit wrote: >>>>>>>> On 9/15/2023 7:37 PM, Morten Brørup wrote: >>>>>>>>>> From: Ferruh Yigit [mailto:ferruh.yigit@amd.com] >>>>>>>>>> Sent: Friday, 15 September 2023 17.55 >>>>>>>>>> >>>>>>>>>> On 9/8/2023 5:07 PM, Mykola Kostenok wrote: >>>>>>>>>>> From: Christian Koue Muf >>>>>>>>>>> >>>>>>>>>>> The NTNIC PMD does not rely on a kernel space Napatech >>>>>>>>>>> driver, thus all defines related to the register layout is >>>>>>>>>>> part of the PMD code, which will be added in later commits. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Christian Koue Muf >>>>>>>>>>> Reviewed-by: Mykola Kostenok >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Mykola, Christiam, >>>>>>>>>> >>>>>>>>>> This PMD scares me, overall it is a big drop: >>>>>>>>>> "249 files changed, 87128 insertions(+)" >>>>>>>>>> >>>>>>>>>> I think it is not possible to review all in one release cycle, >>>>>>>>>> and it is not even possible to say if all code used or not. >>>>>>>>>> >>>>>>>>>> I can see code is already developed, and it is difficult to >>>>>>>>>> restructure developed code, but restructure it into small >>>>>>>>>> pieces really helps for reviews. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Driver supports good list of features, can it be possible to >>>>>>>>>> distribute upstream effort into multiple release. >>>>>>>>>> Starting from basic functionality and add features gradually. >>>>>>>>>> Target for this release can be providing datapath, and add >>>>>>>>>> more if we have time in the release, what do you think? >>>>>> >>>>>> I was expecting to get only Rx/Tx in this release, not really more. >>>>>> >>>>>> I agree it may be interesting to discuss some design and check >>>>>> whether we need more features in ethdev as part of the driver >>>>>> upstreaming process. >>>>>> >>>>>> >>>>>>>>>> Also there are large amount of base code (HAL / FPGA code), >>>>>>>>>> instead of adding them as a bulk, relevant ones with a feature >>>>>>>>>> can be added with the feature patch, this eliminates dead code >>>>>>>>>> in the base code layer, also helps user/review to understand >>>>>>>>>> the link between driver code and base code. >>>>>> >>>>>> Yes it would be interesting to see what is really needed for the >>>>>> basic initialization and what is linked to a specific offload or configuration feature. >>>>>> >>>>>> As a maintainer, I have to do some changes across all drivers >>>>>> sometimes, and I use git blame a lot to understand why something was added. >>>>>> >>>>>> >>>>>>>>> Jumping in here with an opinion about welcoming new NIC vendors to the community: >>>>>>>>> >>>>>>>>> Generally, if a NIC vendor supplies a PMD for their NIC, I expect the vendor to take responsibility for the quality of the PMD, including providing a maintainer and support backporting of fixes to the PMD in LTS releases. This should align with the vendor's business case for upstreaming their driver. >>>>>>>>> >>>>>>>>> If the vendor provides one big patch series, which may be difficult to understand/review, the fallout mainly hits the vendor's customers (and thus the vendor's support organization), not the community as a whole. >>>>>>>>> >>>>>>>> >>>>>>>> Hi Morten, >>>>>>>> >>>>>>>> I was thinking same before making my above comment, what happens if vendors submit as one big patch and when a problem occurs we can ask owner to fix. Probably this makes vendor happy and makes my life (or any other maintainer's life) easier, it is always easier to say yes. >>>>>>>> >>>>>>>> >>>>>>>> But I come up with two main reasons to ask for a rework: >>>>>>>> >>>>>>>> 1- Technically any vendor can deliver their software to their >>>>>>>> customers via a public git repository, they don't have to >>>>>>>> upstream to >>>>>>>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fdpdk.org&c=E >>>>>>>> ,1,N >>>>>>>> poJejuuvPdOPfcFJYtsmkQF6PVrDjGsZ8x_gi5xDrTyZokK_nM11u4ZpzHgM10J9 >>>>>>>> bOLl nhoR6fFAzWtCzOhRCzVruYj520zZORv6-MjJeSC5TrGnIFL&typo=1, >>>>>>>> but upstreaming has many benefits. >>>>>>>> >>>>>>>> One of those benefits is upstreaming provides a quality assurance for vendor's customers (that is why customer can be asking for this, as we are having in many cases), and this quality assurance comes from additional eyes reviewing the code and guiding vendors for the DPDK quality standards (some vendors already doing pretty good, but new ones sometimes requires hand-holding). >>>>>>>> >>>>>>>> If driver is one big patch series, it is practically not possible to review it, I can catch a few bits here or there, you may some others, but practically it will be merged without review, and we will fail on our quality assurance task. >>>>>>>> >>>>>>>> 2- Make code more accessible to the rest of the world. >>>>>>>> >>>>>>>> When it is a big patch, code can be functional but lots of details, reasoning, relation between components gets lost, which makes it even harder for an external developer, like me, to understand it (I am a mere guinea pig here :). >>>>>>>> >>>>>>>> If a customer would like to add a feature themselves, or fix something, even after vendor no more working on that product anymore, customer needs to understand the code or some reasoning in the code. >>>>>>>> Or if someone wants to backport the driver to rust, or a DPDK developer wants to do a rework that requires updating all drivers, or a tester would like to analyze the code to figure out behavior difference of the devices. I think I have witness all above cases in real life. >>>>>>>> >>>>>>>> If driver is split into more patches, it makes patch easier to understand which makes code practically more accessible to other developers that are not expert in driver. >>>>>> >>>>>> I fully agree about the 2 reasons for upstreaming piece by piece. >>>>>> >>>>>> >>>>>>>> Overall, yes splitting patch takes time and effort, and yes this is an overhead for a code that is already developed, but I think benefit is big so it worth doing the task. >>>>>> >>>>>> In the meantime, if some features are not yet upstreamed in a >>>>>> release, a user can apply the missing patches from the mailing list to get the features. >>>>>> >>>>>> >>>>>>>>> We, the community, should not make it too difficult for vendors trying to upstream their drivers. I certainly consider it unreasonable to ask a vendor to postpone the release of some existing features by effectively an entire year (considering that only LTS releases are relevant for most of us) because we want the vendor to refactor the patch series to match our preferences within an unrealistic timeframe. >>>>>> >>>>>> You're right Morten, we try to be as welcoming as possible, but as >>>>>> Ferruh said, we want to be able to understand how a driver is >>>>>> built, even if not understanding all details. >>>>>> >>>>>> In Open Source, I think not only the code should be available, we >>>>>> must also take care of explanations and documentation. >>>>>> >>>>>> >>>>>>>> Agree to not make upstreaming difficult for new vendors, and indeed we are encouraging more vendors to be upstream their code, this is in best interest of both sides. >>>>>>>> >>>>>>>> Distributing upstreaming effort to a year was just a suggestion, it can go in earlier as it is becomes ready but I can see it will take time to split driver into features and upstream them. >>>>>> >>>>>> Driver features can be added until -rc2 (in one month). >>>>>> >>>>>> >>>>>>>> As I am from a vendor too, I can understand the product/customer pressure, but I hope this approach can encourage vendors start upstreaming early or even better upstream as they develop the code. >>>>>>> >>>>>>> Hi Ferruh, >>>>>>> >>>>>>> First of all, thank you for starting the work to review our code. >>>>>>> >>>>>>> As Morten said Napatech plans to take all responsibility for the >>>>>>> quality of the PMD source code. We expect to provide all fixes >>>>>>> needed in the future. If for some reason Napatech stops >>>>>>> maintaining the code, then we have been informed that the DPDK >>>>>>> community might delete the PMD from the repository, and we understand that. >>>>>>> >>>>>>> In regards to splitting the code, I don't see this a good option. >>>>>>> While I of cause agree it would be easier to review and >>>>>>> understand, the code should also result in a meaningful product. >>>>>>> Of the 87k lines of code, 53k lines is needed to start-up the >>>>>>> FPGA to a state the it is ready to receive traffic. But at this >>>>>>> point all packets would simply be discarded, and to be honest, >>>>>>> there are better and cheaper options out there, if nothing more >>>>>>> than basic functionality is needed. 34k lines are used to setup >>>>>>> filters based on rte_flow. The thing is, that you need to >>>>>>> initialize all modules in the FPGA TX- and RX-pipelines with valid data, even if you don't need the features those modules provide. >>>>>>> As a result, if you split up the 34k lines, then the product >>>>>>> would not be functional. Of cause some of the top level logic >>>>>>> could be split out, but at this point we are talking about >>>>>>> splitting 87k lines into 80k and 7k, which I don't think is worth it. >>>>>> >>>>>> Actually I think it is worth. >>>>>> There is a benefit in isolating the small basic init part from the >>>>>> more complex features. >>>>>> >>>>>> >>>>>>>>>> As far as I understand last patch opens a socket interface and >>>>>>>>>> an external application can sent control commands via this interface. >>>>>>>>>> I am not sure about this side control channel, what is missing >>>>>>>>>> in the DPDK API? Can we try to address them in the DPDK layer >>>>>>>>>> instead of a driver specific solution? >>>>>>>>> >>>>>>>>> That would be great. >>>>>>>>> >>>>>>>>> AFAIK, other vendors also has a bunch of out-of-band >>>>>>>>> communication, e.g. magical EAL parameters to the MLX drivers. >>>>>>>>> So let's not be too hard on the newcomers. ;-) >>>>>>>>> >>>>>>>> >>>>>>>> I did some thinking for this one too, >>>>>>>> >>>>>>>> As we are in userspace, it is easy to have side control channel, and this can make users life easy, so this is a practical thing to do. >>>>>>>> (Indeed there are already some ways to do this, without PMD >>>>>>>> exposing a socket interface.) >>>>>>>> >>>>>>>> But this also reduces effort developers putting on DPDK layer solution, because it is always easier to add more support to the driver only. >>>>>>>> And overall this reduces portability of the DPDK application, >>>>>>>> each application becomes unique to a device (This is a bad >>>>>>>> thing, but I also need some feedback how bad it is in real >>>>>>>> life.) >>>>>>>> >>>>>>>> To balance this, we said if a feature is too specific to a device, it can add device specific API and this is better than device specific features pollute the common, most used code. And push back to introduce more new PMD specific APIs unless it is really needed. >>>>>>>> >>>>>>>> But creating a socket interface directly from the driver is more than PMD specific API. Technically application control interface can rely completely to this. Even we assume this is not for control, but just for debug, I can see it can be useful for debug and again practical thing to do, I am still not sure how much it hurts if each driver has a custom socket interface for their debug needs. >>>>>>>> >>>>>>>> Overall it makes more sense to me to have a unified/common interface from drivers to DPDK applications, which is through the ethdev layer. >>>>>>>> And improve and extend the ethdev layer to satisfy driver needs. >>>>>>>> >>>>>>>> In this specific example, I am for rejecting the socket interface patch, but I would like to get more feedback from @techboard. >>>>>>>> >>>>>>> >>>>>>> The reason we have the addition control channel is not provide >>>>>>> additional functionality. We have customers with use-cases that >>>>>>> require multiple processes. Since Napatech adapters do not >>>>>>> support configuration through VFs, then secondary applications >>>>>>> must send their rte_flow to a main application, which will then >>>>>>> setup the flow through it's PF. This control channel "hides" >>>>>>> these details, and make the product easier for users to adapt to their existing solutions. >>>>>> >>>>>> I think you need to explore VF representors. >>>>>> This is what is done with other drivers, and it make them compatible. >>>>>> >>>>>>> If you stand firm on rejecting the control channel, then we have >>>>>>> to go back to the drawing board on this issue. We did look at >>>>>>> DPDK's multi-process support, and actually had some support for >>>>>>> this, but we determined that for our use-case it was better to >>>>>>> have a communication channel, and no shared memory. >>>>>> >>>>>> I'm not sure your need is about secondary process. >>>>>> Let's discuss this need in a meeting if needed. >>>>>> Anyway, the message is that we want to be part of such design decision. >>>>>> >>>>>> >>>>>>>> And related to not being too hard on the newcomers, unrelated to being a newcomer or not, if a process/feature/approach approved once, some others will point to it and will ask to do the same which is fair in their perspective. I had multiple instance of this in the past. >>>>>>>> >>>>>>>> Of course we are being easy to newcomers but not in a way to >>>>>>>> allow code that we believe is not good thing to do, but going >>>>>>>> easy on process may be :) >>>>>>>> >>>>>>> >>>>>>> We are grateful for any leniency you may show us ;-) >>>>>>> >>>>>>> Thanks again, >>>>>>> Christian >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> ferruh >>>>>>>>> >>>>>>>>> Thank you, Ferruh, for taking good care of the community by providing constructive feedback like this to new NIC vendors! >>>>>>>>> >>>>>>>>> Please note that my feedback is entirely process related. I didn’t review the driver, so I have no technical comments to the patch series. >>>>>>>>> >>>>>>>>> -Morten >>>>>> >>>>>> >>>>>> We are going to discuss the process in the technical board today. >>>>>> >>>>>> >>>>> >>>>> Hi Mykola, Christiam, >>>>> >>>>> As discussed, following are a few good examples from the DPDK history, there is no "fits all, fixed guidelines", but they can serve as samples: >>>>> >>>>> Marvell cnxk: >>>>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpatchwork.dpdk. >>>>> org%2fproject%2fdpdk%2flist%2f%3fseries%3d17449%26state%3d%252A%26a >>>>> rchive%3dboth&c=E,1,DmXU0iHwXoSaZ4bKn-yhX9J8XmFBispd2ut7pxLNBkK3Q4L >>>>> VpG_zmOf1jnWSS-Y0Fx-TNbPnQDHyBZkDj23Gu7zjPZ5nsA7pid5CsE2vxNk,&typo= >>>>> 1 >>>>> >>>>> >>>>> Solarflare sfc (before patchwork series support): >>>>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpatchwork.dpdk. >>>>> org%2fproject%2fdpdk%2fpatch%2f1480436367-20749-2-git-send-email-ar >>>>> ybchenko%40solarflare.com%2f&c=E,1,E9oUT_1WuNC2JA8x7an3rC_Pm5g1L5cx >>>>> JKQ6pTwSbCWSJpiLH2GnmgfFkUqViOOwkpS2df8kgBvHjmulKaWhyr4BBizUT-sL5LJ >>>>> v21Hx4RtHtK3vjhcKpg,,&typo=1 >>>>> to >>>>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpatchwork.dpdk. >>>>> org%2fproject%2fdpdk%2fpatch%2f1480436367-20749-56-git-send-email-a >>>>> rybchenko%40solarflare.com%2f&c=E,1,GByF_TiC_q11iVPpiPgpCMlSge-J0Xf >>>>> T0zHkriK0rde1Qt1RG7uf6mETQkTSQ-1V86Z7EtRcxlvSsed1sqn8RWfN8KFSbd7NaA >>>>> kfbDiehn_vSRzja45rQgv53Q,,&typo=1 >>>>> >>>>> >>>>> Intel ice: >>>>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpatchwork.dpdk. >>>>> org%2fproject%2fdpdk%2flist%2f%3fseries%3d2842%26state%3d%252A%26ar >>>>> chive%3dboth&c=E,1,zQwvAIR3ToLIhT09bVxm_HEF-dp8eyTqhsKB3eOYgIJdd2WS >>>>> _0ZlTbQKfr9KLyTA3A2A2HzBbjIlz21D_hWVgS_INmmC5eew1J0QBH-PoRNd&typo=1 >>>>> >>>> >>>> Thank you for the links, they have been very helpful. >>>> >>>> After a lot of internal discussion, Napatech has decided to implement some architectural changes to our PMD that will allow us to easier split up the code into smaller features. The work will require some time, which means that we will not be ready for the 23.11 release. The current goal is to attempt to upstream a quite basic PMD in time for 24.7, and a fully featured PMD for 24.11. >>>> >>>> >>> >>> Hi Christiam, >>> >>> Good to see there is a solid plan for upstreaming but also not that >>> good that it is postponed, >>> >>> I am aware it is all tied to your internal planning/resourcing etc, >>> but since the effort already started, can it be possible to squeeze >>> very basic driver in this release, which just does link up and most basic Rx/Tx? >>> It gives opportunity to experiment on device to users. >>> >>> We can accept it up to -rc3, which is end of October, so there is >>> still some time? >>> >>> This is just a suggestion though, no pressure intended. >> >> I agree with Ferruh, better to start early and small. >> It shouldn't be too hard to introduce the skeleton of the driver. > > Hi Ferruh and Thomas, > > My apologies for the late response, I have been sick the last week. > > We can try to create a small PMD in time. The reason I'm cautious is because Napatech plan to make quite large changes to the PMD, to achieve a more stable and modular code-base. This means that future updates will have quite large diffs, until these changes are in place. > > Hi Christian, Mykola, What is the status of the 'ntnic'? Will there be some upstreaming effort for v24.07?